weland

Shit man, at this point I'm wondering if I'm not actually working for the CIA's industrial sabotage training department. That list is basically an SoP.

That's neat! Thank you for the explanation!

> For example say you want to have a "first" operator that takes the first item of a container, but also works on individual values if they aren't containers:

But why would I want to do such a thing? Not only does first() not make sense for non-container objects -- but calling x.first() when x is a non-container object is a bug 9 times out of 10 (i.e. something got unpacked when it shouldn't have, an [x] (a single-object vector) ended up x (i.e. the first and only value of that vector).

Ha! Ok, this one makes sense. Thanks!

Nonetheless, Red Hat really is doing a lot of upstream development, certainly more than Debian does as far as I know. Indeed, the Debian community has managed to keep their release schedule and meet their goals lately, so they're probably in a better shape than "barely enough to support itself", but there hardly seems to be room for comparison between the two.

I'm a little... confused is maybe too strong a word for this, I just don't really grok this:

> As you can see, during serialization, it comes pretty handy to be able to check if an object has an attribute and to query the type of this attribute. In our case, it permits us to use the serialize method if available and fall back to the more generic method str otherwise.

I would actually prefer if, during serialization, the compiler would yell at me that object C doesn't have a serialize method. For one thing, it's very likely that, while it does have a toString() method, it doesn't have the corresponding fromString() method, making the serialized output useless. For the other, in a sane architecture, if an object does not have a serialize() method, then it's either: a) because it shouldn't be serialized in the first place, whatever the reason, or b) because it should have a serialize() method, but it has not yet been implemented (and it should!)

I understand that this is "didactic" example. Does anyone know of a more real-life/relevant example where this can be used? SFINAE (Substitution Failure Is Not An Error) looks neat as a language feature but I don't really see where it's useful (in fact, it looks like a bug that was repurposed as a feature).

Red Hat has no reason to care about platforms like BeagleBone Black.

Yeah, "the joy of getting X to run" part didn't really resonate with me, either :-)

> This makes me feel old. I look at those desktops (particularly the Windows 95 one) and think they look clean and neat, with few distractions.

They also look like someone tried to come up with their own ideas. Everything today is flat, sketchy, inexpressive and boring.

> How I miss Netscape, the feeling of discovering something new in computers that made you go "wow" (IE4 and DHTML), or the feeling of "this is really great and USEFUL" instead of "this is really pretty", the joy of getting X to run, or learning a new Linux command whilst stuck in the CLI, getting VNC to work, doing X-window forwarding. I miss the lack of Internet, the fact that knowledge of systems came through hard work and patience, through reading and waiting for the next month's magazine that I bought with my paper-round money. I truly am an old fart.

I sometimes find myself thinking the same, but I guess it's the slow pace that allowed me to fixate that knowledge that I miss. We made a lot of these discoveries by piecing together various puzzles. It forced us to think what happens "underneath".

Nowadays, when everything is a "how to X" Google search away, you need a little discipline to keep thinking, instead of blindly following instructions.

My guess is that you need to have the kind of wavelength that meaningfully interacts with human features and body composition (i.e. something that scatters and reflects off of you, instead of being absorbed). It's not specific to the WiFi spectrum though, there are plenty of frequency ranges that meet these requirements.

You should look into Apple's history a little. Their management at the time was not significantly better than Commodore's, and Apple wasn't too far away from going under the same way Commodore did.

Disclaimer: I'm (technically) an engineer, not a physicist, but I took a course on this back in uni, and as far as I can remember, you're correct. The gist of it is that BCS theory, which satisfactorily explains conventional superconductivity, fails to predict the behaviour of high-temperature superconductors, and there simply isn't a better model available at the moment.

For any sane individuals reading this, the answer is "We're trying really hard but so far we haven't been able to deduce a formula for the highest temperature."

I'm not very optimistic with regards to this ever happening. I remember reading a paper regarding one of the many high-temperature superconductors, BSCCO; it has a crazy crystaline structure, it's quite unlikely that we'll ever come up with an analytical model describing its superconductive behaviour.

The vitality of the Amiga community never ceases to amaze me.

I actually headed over to A-Eon's page. I've been postponing getting one of their systems for about three years now, for various reasons, and I finally thought I'd say yes.

Sadly, it turns out they're all discontinued: http://www.a-eon.com/?page=products .

For all the awesomeness of AmigaOS 4, the hardware continues to be sadly elusive, as it has been ever since the demise of Commodore.

That's largely because you still have the package manager to resort to in order to take care of most dependencies. Prior to that, you'd still have to install (a lot of) dependencies by hand. Not all of them used autotools, not all of them used standard install locations by default... it was pretty atrocious.

In fact, I remember that one thing which kept me on Debian for a long time was that it had so many available packages. Back then Debian was even slower than today and many of those packages were a little old, but it didn't really matter to someone who was just discovering things.

It's easy to forget about them, but package maintainers are incredibly important in today's Linux (and *nix-inspired in general) world. There's a lot of hard work behind the fact that you can just apt-get whatever new program you found out about.

It was somewhat tongue-in-cheek -- you're right, I should have made that clear. I was referencing a tweet in which one of you was (jokingly) remarking how many FreeBSD developers seem to run something else on their laptop.

If you don't depend on anything that Windows or Linux-specific, it is :-). Modern standards for portability are a bit... relaxed, to use an elegant word.

But yeah, OpenBSD makes a very good desktop OS.

OpenBSD also has a pretty good "eat your own food" policy, which is why (unlike in the case of other COUGHFREECOUGH BSDs) you won't see OpenBSD developers running OS X.

I've seen the opposite end of the spectrum, too, though, which is why I don't think talent is only a lot of practice, I just think that you can be very good at something without being one of those "really talented" people.

I have another acquaintance who's a musician (an actual musician, unlike me -- I'm just a programmer who likes playing the drums). The guy obviously had a lot of practice, especially as he graduated a famous music academy so he had to play the violin a lot.

That being said, he started taking violin lessons when he was 6, but by that time he could play it pretty well. Having realized that he can't remember the songs he was inventing, he even developed his own rudimentary notation system (when he was about four), with horizontal lines whose length indicated direction and a combination of dots and relative heights to indicate pitch relative to the first note of the song, so that he only had to remember where to start from. His violin technique was also remarkably good. When he started giving violin lessons himself, he struggled with understanding the first gripes of beginners a lot more than he'd expected. For instance, he never realized it takes so long to learn how to properly angle the bow when playing the second and third string of the violin (they're at almost equal height with respect to the base of the resonance box, so most beginners will unintentionally stroke both at the same time). Not only did he not remember having that problem, he literally never really imagined that someone could have that problem.

He's one of those people who does have an innate talent; there are a lot of techniques that he never learned, nor really "discovered" through an iterative process, he just figured out it would sound good if he did <something>, and it did. His brain was wired in a manner that's favourable to playing the violin and to music in general.

Needless to say, he still had to practice a lot -- he had to learn "proper" notation, he's constantly refining his rhythm and coordination, he had to learn how to play in an orchestra, and it's not like he could play any piece, no matter how difficult, from the very beginning. But there were things which his mind and his body could do without being taught, or which, at least, they discovered a lot more quickly than others did. They weren't enough to make him an orchestra-level musician from the moment he set his tiny three year-old hand on a violin, but they are certainly enough to set him apart from a lot of musicians of his age and experience.

The point I was trying to make is that there is no widespread innate aptitude that makes you magically produce amazing programs when you touch a keyboard for the first time, and anyone who does not have that innate aptitude is bound to write shitty web apps for the rest of his life. You look at people doing something that they're very good at and it seems easy, it looks almost like they have an instinct for it. It seems like they're born with it, but most of them aren't.

Here's a little story that I tell to anyone who asks me this question. It's how I got it answered for me a long time ago.

> How can I tell if I have programming aptitude?

I have a friend who's a painter. She's a visual artist with a fair deal of success; she can actually live out of her art (and by that I mean she actually sells her paintings for a living, she doesn't just design logos to buy her a little time for her real occupation on Friday evenings).

We were gathered at her house for a gig and waiting for the guitarist to show up (as usual), and while we were each rehearsing various bits and pieces, she sat on an armchair across from me and casually picked up a piece she had almost finished, and began applying some finishing touches. I'd never seen her painting before, so after I picked up my jaw from the floor, I passingly remarked that I'm a little envious on anyone who has a talent for drawing.

(Background: my depth perception is basically shit because of a limp eye. The only reasonable drawings I ever made where in Geometry classes).

Her reply was along the lines of dude, look, the ones who have a talent for this are the likes of Picasso and el Greco. Everyone else, even those of us who paint a lot better than anyone else you can find on the street, just practiced a lot.

She then proceeded to show me a couple of things she had drawn when she was a kid, long before she decided she wanted to do that for a living. Surely enough, they looked much like any other kid's drawings. They were a little less "hurried", as she obviously loved doing it and spent more time on a drawing, but were otherwise indistinguishable from other childrens' drawings. Even later ones, from around the time when she had decided she really liked this, weren't exactly breathtaking.

tl;dr: You have the "programmer aptitude" if:

a) You're a frickin' genius who can talk to computers as if they were kindred spirits, but then I guess you wouldn't be asking this if you were, or b) You like programming enough that you can do a lot of it, and can tolerate spending that time looking at your programs with a critical eye and seeing where you failed and what you can improve.

The pitfall in b) is that it will consistently make you feel like a failure, but hey, that's life man.

I bet strongly against that simply because large commercial players in the field center a significant part of their business around hoarding users' data.

Even if they somehow figured out how to scale decentralized systems and keep them reasonably spam-free, they wouldn't want them.

Folks, please read the article. This has nothing to do with Docker.

It's referring to bundling as part of RPMs, i.e. on having application packages bundle some or all of its dependencies along with the application. This is generally frowned upon, and with good reason, but it's being practiced with an increasing frequency.

The Fedora devs have had a lot of problems with this over the years. More recently, libraries like rawspeed have sprouted everywhere -- they are meant to be used only as bundled libraries.

So they either had to change the rule and allow bundling, or to find themselves unable to distribute applications that are otherwise useful to developers, I guess. They "opened up to bundling" in that they introduced a new provision which allows bundling in cases where there's no alternative, but the RPM has to be marked as including bundled dependencies.

Don't get me wrong, I'm all for bashing Red Hat's perpetual beta crap distro, but this time they got it right. Really. It's a sensible decision, not some wavefront of Linux innovation bullshit.

I haven't read the scientific article article in question, so I cannot challenge the statistics (if any) or the methodology (since I don't know it), but I'm curious if there's any guess about the underlying mechanism here. Because it sounds a little fishy to me.

My native language is one of those that would supposedly make it easier to count beyond 10 (i.e. if you go back long enough in the linguistic history, 11 would be translated as "one [unit] after/on top of ten"), but the generalization is awkward: 21 is roughly "two tens and one". You have to remember about as many rules as in English (eleven and twelve are awkward, the rest aren't. My whole touted advantage would be in only two numbers.).

Furthermore, the positional system often means that, when you're computing "11 + 13" as a kid, you don't even say the words eleven and thirteen while performing the addition.

Besides, if complexity of the numerical system would be an indication, no one in France should know math. Quatre-vingt-dix-neuf is a frickin' lesson in arithmetic all by itself. I think 90% of the awkward conversations I've had in French were "please show me the numbers on the screen because I have no idea what you're mumbling there" at the supermarket.

This is highly anecdotic and I'd be happy to counteract it with the opposite experience. Whenever I spend enough time in the outdoors (I used to go camping regularly until a few years ago), I'd end up sleeping less and going to bed later. I'd generally end up sleeping for about 6-7 hours, from 01:00 or so -- and feeling a lot better in the process.

Not really, although the technique employs a look-up table. The basic idea is that they found that many instruction sequences that cause a mis-speculation once tend to cause it again in the future. This is done in the context of ILP -- mis-speculation means that the processor thought an instruction doesn't need data from a previous one and it executed it in advance, but then it turned out that the result did depend on a previous one, so the first result was retired and the instruction was executed again.

In order to avoid this from happening too often, they added a(nother) feedback loop in the whole process: if a sequence of instructions seems to cause a mis-speculation often enough, it's added to a table, so that when it's encountered again, the control unit doesn't speculatively execute an instruction whose result is most likely going to have to be retired anyway.

I don't know if there's prior art to this, but the basic idea is fairly straightforward. I wouldn't be surprised to learn that IBM or DEC engineers knew about this prior to 1996.

> I'm going to argue that direct public funding is the best way, and by that I mean the historical analogy of direct patronage or crowdfunding research today (e.g. experiment.com).

Sadly, you'll be hard-pressed to do direct public funding in anything that is not publicly-attractive. You'll get a gazillion bazillion dollars for research on canabinoids, and barely a dime on some boring ray-bending materials research problem that will eventually turn out to be easy to integrate on an organic substrate, opening the way for silicon-on-organic optoelectronic devices.

The "average citizen or constituent" has a level of scientific education that would prove at least as, if not more toxic than commercial interests. The current (absolutely terrible!) grant funding model is indeed too technical for the "average citizen or constituent"; a frickin' k-12 textbook is too technical for the average citizen, of course high-level research is too technical! That's why it's high-level!

> If you were motivated to go out and seek an answer for yourself, then perhaps you'd be less likely to lean on witnesses, testimony, or experts that you don't understand.

That's how we ended up with the anti-vaccines craze. People are motivated to go out and seek an answer for themselves, but they're also lazy and seek comforting answers.

> You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine.

What was intelligent about that?

I don't need intelligent tools, I need tools that do what I say! That's why they're tools, damn it!

> I'd say it's a matter of debate how good that control is when who's controlling it is either incompetent or has it's own interests -- or worst, both.

The problem is that, in the example quoted, no one had that control. Gold mines run dry and you're fucked. Not because some incompetent banker is controlling the gold supply, but because there is no more damn gold. The most competent financial advisor of Rome -- a figure so gargantuan in the field of finance that, if transplanted to the modern world, would not only win that fake Nobel prize for economics, but would cause every other economist to retire out of shame -- would have been powerless. Because there was literally no more gold.

Obviously, it wasn't the end of all things -- new mining facilities would be open, sometimes processes would be optimized in older ones, wars would be waged, but these things took time and needed money.

> Yeah good luck setting up a startup now. If other countries follow Russia's suit, we'll soon end up having to somehow determine where a user is from (what if they're roaming, etc.?) so we can shard the datastore across multiple geographic locations.

Or just host everything in Europe.

Or lobby Congress to stop shitting all over privacy so that the US can be considered a safe harbour again.

The whole term is ridiculous:

> a more child-centered approach to parenting

What other approaches to parenting are there? Cat-oriented?

I can confirm this. I have an acquiantance who is a medic, far away from Norway. He's in the same boat. A few years ago, when they switched to their new system, he mentioned to me that one of the reasons he's so unhappy with the new system is that he cannot talk to the patient while looking up his information. He has to stop and focus on the screen. This introduces some bouts of awkward silence which is all the more unpleasant when the guy you're talking to is worried about his health.