dialamac

You win.

I’m glad you think highly of your poetic abilities, but I have no desire to engage in that pointless argument.

Edit: and yes.. uh comment deleted as charged, since you had edited after I replied.

[See screenshot]

I’m amused that a number in this thread saw these observations as a “diss”... that’s more on you then me. I didn’t pass any value judgement on these differences, merely that they exist and demonstrate some fundamental differences in the history of these languages. While Ruby lambdas are essentially first class anonymous functions they were added late in the language and they are distinct from methods that predate them. You can’t just drop them in seamlessly where a method is used. The point stands that while both Ruby and python have accreted more stuff as time wears on, their initial design principles were starkly dissimilar.

I don’t think that is an indictment of the moderation system. You can’t replace a dead community with excellent moderation. Slashdot’s dead because it failed to produce worthwhile content and not be an even uglier pile of ass. The mod system can’t do anything about that.

> The last time it hit, at a Chinese restaurant in SF,

Not to not take it seriously, but isn’t there a lot more stuff in American Chinese food other than MSG? Like of the 1000s of chemical substances that would be in a plate of Chinese food, why of all places would that be where you would isolate an MSG allergy?

> or adulterant that travels with commercially produced MSG

Then that wouldn’t be an MSG allergy. Oats are gluten free but celiacs have difficulty with them, not because of the oats but because of contamination.. we wouldn’t say they have an oat allergy though.

> the language designs are so similar that I could just as well imagine a world where Python is the web development lingua franca, and Ruby has all the machine learning libraries.

Well aside from the startling implication that Ruby is a web development “lingua Franca.”...the latter statement is reasonable, as it turns out language design isn’t actually that important here. But the former is pretty far off the mark. I mean, Ruby doesn’t even have first class functions and is very strongly smalltalkish in its OO purism, it has mutable strings a-la Perl. The async story is obviously quite different. Python has a much more complicated interpreter, which has contributed to it being more difficult to get even simple optimizations that are done in Ruby. They’re really only similar in the most superficial sense... in the same way that all current dynamic interpreted languages will do certain things similarly.

Old 78 records were produced with equipment from recording to cutting and pressing that is long since obsolete. Even if you overcome the challenges of dealing with laser equipment (dust, tracking).. what extra information are you really getting?. that it is useful signal more than even a dB or two above the noise I think is very wishful thinking.

> This is the trouble with audio in general: people not only prefer different sound profiles but also perceive sound differently, which makes it difficult to get rips (at least in my limited experience).

The problem with worrying about this is that even the same person perceives sound differently situationally and is simply not repeatable. In most cases when someone hears a difference it is often just a change in their perception from one moment to the next.. and that’s even when something measurable has changed! The bass sounds better because of that new amp.. well no.. you just happened to focus on it more the second time around. Longer term people’s physiology changes as well.

Only repeat, blinded A-B testing can clearly elicit an objective difference that is most likely not due to these perceptual inconsistencies.

What does this mean.. record it with decent equipment that captures as much useful raw information as possible (and yes 96khz is ridiculous as we’re not bats). People can EQ and mix to their preferences any given day.

It’s not clear there was something wrong with the cartridge. These are old 78 records.. they weren’t mastered with much to begin with and the useful fidelity in them is limited. If you want you can post-process them with whatever fancy shit, but I wouldn’t immediately assume the recordings weren’t the best given what they were working with for source material.

This is about C, not C++. Though I haven’t been there in years, I chuckle to think what would have happened if you made this mistake on that news group.

You have no evidence to back this claim up, because it’s not true.

Um.. no it wasn’t. Git was a complete trash fire on Windows when GitHub was founded for one.

I started using git when I was working on embedded Linux professionally in 2005, witnessing the whole bitkeeper saga. I am keenly aware of the history of DVCS 15 years ago.

Meanwhile outside the bubble of academia and startup web devs in 2008, Windows was still by far the most widely used dev platform. I typically deployed Mercurial when I wanted to convince a wider technical audience others of the beauty of DVCS.

GitHub felt safe the same way Instagram (among many) felt safe deploying for iOS only, even when then Android had a larger user base. There are other factors at play, and it was not that git had some kind of major advantage in 2008. If anything mercurial had a slight edge. But if anything in 2008, the wider DVCS market was still in its infancy.

My guess, probably because they’re idiots.

“ A lightweight, standard publish/subscribe mechanism should be identified; possibly something like MQTT (which would have the added benefit of allowing for network-wide communication). In the meantime, the use of D-Bus as a legacy technology may be acceptable (even though it is considered obscure, convoluted, and closely linked with various other Red Hat technologies.”

This sort of sums it up right there. I mean I think dbus is a trash fire, but not because it is tied to RedHat, and “something something” hand wavy MQTT isn’t a real solution.

This seems to be more of a project driven by Linux hate then actual design principals. The former is not so much a problem as the latter

I mean git is wildly popular because of GitHub, and probably that was something to do with it in the Rails community... a community that if anything is culturally the opposite of the kernel dev community (or at least very different). I don’t think any kernel dev influence had to do with it, even though it’s often stated as a fact.

Love that it was a “hacker” rather than a bored teenager or some casual idiot, or even a disgruntled former or current employee. Invoking the hacker term I guess is supposed to make it absolve gross negligence in even the most basic security practices. It makes me sad to think this spin actually works.