In my experience LSD makes you THINK you are having great epiphanies but if you actually record yourself or write them down they aren't very wondrous and usually not even coherent in the morning.
Generally true, but back in late seventies or early eighties, I actually designed and implemented a debugging tool while tripping balls. It was in use throughout the company within a week. It actually came to me in a vision.:)
Of course, when it comes to psychedelics, "You Mileage May Vary" has never been more true. There seem to be no consistent effects from person to person. Even dilated pupils turn out not to be universal (although it's the closest that's been found). Just because I was (at least once) able to direct my hallucinations in a useful direction doesn't mean someone else will.
C# is a great language , Java is a great language , Perl is a great language , C is a great language, Scala is a great language, Lisp is a great language.
You're confusing languages and VMs. Java-the-language is perfectly adequate*; Oracle's JVM is a very dubious beast. Of course, you can always get a native compiler (I have one, though I've never used it), if you really love Java, and don't trust the JVM. Though that won't help you with applets.
I agree with the main thrust of your post: the problem is applets and browsers and trust, not languages, but you seemed to be confusing the matter while trying to clarify, so I thought I'd supply a little real clarification.
* After over a quarter-century as a programmer, I have yet to see a language I would describe as "great". Adequate to the task at hand seems to be about as good as it gets, and even that's more rare than it should be!:)
Using a striping arrangement (or striping with parity)
Ah, I see your mistake. You saw "raid", and assumed he was talking about striping, rather than the more obvious (since he then mentioned "redundancy") mirroring (e.g. RAID1). I'm not sure if that's a case of you having too little knowledge or you assuming too much on his part. I would have said mirroring if I meant mirroring, to avoid the potential for confusion, but I certainly figured he meant RAID1, even though the term "raid" is more commonly associated with striping.
I think it was pretty obvious that he had mirroring in mind, since what he actually said was "using a software raid (redundancy etc)". (Emphasis mine.) That's the only place he mentioned RAID, so I seriously doubt his goal is striping!:)
If you don't trust the provider to keep your data intact, don't use that provider.
That's either a ridiculous statement, or completely off-topic. When it comes to reliability, trust isn't an absolute yes/no thing--it's measured in percentages. And redundancy multiplies reliability, so it's a big win.
There's a trade-off for complexity here, and it's possible to question whether all the extra effort is really worth the potential gains in reliability. (Is it really that important to have eight nines instead of four, or ten instead of five?) But there's nothing wrong with investigating the possibility. And he didn't say anything about price. Or amount of storage. Perhaps he's perfectly willing to pay $10/mo three times over, just for the satisfaction of knowing his data is super available.
For that matter, nobody, no matter how reliable, can guarantee you absolute security. Security is also something you have to measure in percentages (though it's a lot harder to estimate accurately). Encrypting your data gives you an extra layer of protection, even if you think your provider's security is good.
More relevant (since the one you mentioned was covered in the summary) is this: Real World Code Sucks, from a few weeks ago.
There are a lot of reasons why real-world code doesn't resemble the stuff you saw in school. Some are good reasons, some are not. The problem domains in the real world are usually a lot more complex than the ones you encounter in school, which is a good reason. Deadlines and the pressure to make it work, rather than make it right are bad (but unavoidable) ones.
Writing maintainable code is great in theory, but the problem with it is that people maintain it, and the result is usually less maintainable than the original. It's a paradox that should have a name.:)
Anyway, what this definitely has in common with the previous article (the "How can I explain..." one) is that we don't have enough information to judge who's right. Chances are high that both sides have valid points, but it's impossible to be sure from the outside.
There is no ASCII mu. ASCII is a seven-bit encoding which only covers unadorned latin alphabetic characters, arabic digits, and some random punctuation. Even latin1 (aka ISO8859-1) lacks a mu character. I'm not sure what you think you typed, but it definitely wasn't ASCII.
There's also the problem of potential confusion between U+00B5 MICRO SIGN and U+03BC GREEK SMALL LETTER MU (among others), but neither of those is remotely ASCII.
Anyway, yeah, slashdot sucks when it comes to international character support.
Except that the study explicitly showed that population density was not a correlate. Which means that that xkcd, while still amusing, does not seem to be particularly relevant at all.
Well, yes, but many of the people I know who use Macs only do so because you can run vim on a Mac. However, vi itself is about as opposite to the general Mac philosophy as you can imagine--and one of the clearest demonstrations ever that "ease of use" and "ease of learning" are not synonyms.
A better example is "polish" versus "Polish"--not only does the meaning change, but so does the pronunciation!
Though my favorite example of the importance of distinguishing cases is the classic sentence, "Help your Uncle Jack off the horse." WIthout the upper-case, that takes on a whole new meaning!:)
Case matters, and case-insensitive filesystems are one of the stupidest inventions ever.
So then they're fine with the way Windows 8 handles it? Because that's exactly what Microsoft demands of computer manufacturers who want to be certified for Windows 8.
Only on x86. The MS requirement for user-control over UEFI only applies to x86 systems. Arm based systems (phones, pads, etc.) have no such requirement.
But yes, I was surprised and pleased that MS included those requirements, even if it was just for x86, and I'm sure the FSF was as well.
The drivers are not as independent as you think, and system-wide Debian issues are insanely rare--I was a Debian Developer for over a decade, and I only remember one issue that even came close to having the kind of scope that kernel devs see regularly. Furthermore, the kernel is years older than Debian, and, in fact, Debian deliberately looked at (and still looks at) kernel development for ideas on how to manage their system. (And I'm still unconvinced by their elective leadership approach--Democracy has its place, but I'm not sure that "technical lead" is one.)
If you tried pointing at the BSDs, you would have a stronger argument, but the BSDs are, if anything, even more anarchic, with hostile forks happening every time someone loses enough patience with current leadership--and with plenty of assholery-in-charge as well.
Anyway, how the fuck is that an example of him being an asshole? Do you think that anyone who drops an F-bomb is an asshole? You're too fucking sensitive, dude, and I say that with the greatest fucking respect. This is a team that knows each other, usually fairly well, and doesn't stand on formality. Did you even see the part where he says, "I have a stupid trivial complaint"?
Well, speaking as someone who has known one of the founders of the GNU project (Roland McGrath) all his life, and someone who was himself a member of Debian for over a decade, I assure you those are both very different from the kernel. First of all, the GNU project was, for a long time, a Cathedral-style project--in fact, it's the Cathedral in The Cathedral and the Bazaar. Linux is the biggest single bazaar-style project ever. Furthmore, both GNU and Debian are wide-ranging multi-part projects. They are, overall, much bigger than Linux, but Linux is much more of a single thing, while GNU and Debian are huge collections of loosely-related components that mostly operate independently.
When I said Linux was unprecedented, I meant it.
In any case, Linux is not run as an "asshole-in-chief" style project. Linux is rarely an asshole. When he is, it tends to make the front page of Slashdot. That's how rare it is. (Now FreeBSD, on the other hand...):)
Bottom line, Linus has been in charge of the kernel for a couple of decades now, and his process is working. He doesn't flip out very often, so when he does, every who counts knows that some serious fuckups happened. And anyone who doesn't count (which in this case, almost certainly includes both you and me) can probably go fuck themselves if they don't like it.
Nobody in the world knows for sure how to manage a project like Linux. It is truly unprecedented. But Linus's way is working better than anyone would have expected two decades ago. If you want to second-guess him, feel free to start your own competing project and manage it your way. His way is working better than anything anyone else has ever tried, even if it's not "the best way".
Agreed, especially once the kid has accumulated more than one set, the possibilities open up. My nieces usually start by building whatever they're supposed to build, but once that's done, the pieces go in a bucket with all their other legos, and become the basis for all sorts of random things.
It would take a very bizarre child to not recognize the potential for mashups and personal designs.
Well, you can refactor without fear if you're overoptimistic. And when it comes to writing code, aren't we all overoptimistic?:)
But yes, relying wholly on tests assumes your tests are without flaw, which is about as likely as the code being without flaw in the first place. Still, it's better than the alternative--not relying on tests.:)
- Requirements are messy (even not counting the fact that they change constantly) - Textbook code is designed to look clean, but often ignores important edge cases for the sake of simplicity. (See previous point.) - Cleaning up the code may potentially introduce bugs, so once the code gets past QA, it's often considered untouchable until a demonstrable problem is found.
I'm sure there's even more...
(Test-Driven Development (TDD) is supposed to help address that last point, but A) it's not always perfect, and B) it's not universally used.)
I think I can field this one. E17 was developed openly. Some people have been using it for years. The stable release is simply that--it's now considered feature-complete and solid enough to be a 1.0 release instead of a 0.x release.
Having a centralized GUI monitor in the NOC is something that's been around since the '90s, if not longer. That still doesn't require GUIs on the server. The monitor system communicates with the servers with something like SNMP (Simple Network Management Protocol), and can usually be heavily customized to run all sorts of scripts on the servers.
Of course, for some guy running a lone server, a system like this is complete overkill. But that's an edge case.
All of our menu bars, status displays, ribbons, etc*, are horizontal bars on the top or bottom of their respective areas.
Apparently, you've never used AfterStep/WindowMaker, etc., where all the desktop widgets go on the right or left. They've been around since before you could get widescreen displays.
Personally, I'm thinking of adding a second column of widgets and swallowed apps on my right-side dock.
I dunno. There's a big difference between the dreams of controlling the web, which I think MS probably realizes is out of reach, at least for the moment, and the dreams of controlling the office LAN, which still seems to be very much a part of MS's plans.
All the Linux server farms have gotten by without AD just fine, so interoperability there is clearly not crucial, and I doubt we'll see all that many deployments of Samba on the existing farms. It's the IT department and their internal networks that are going to be affected here, and I have a hard time believing that MS is really all that happy about this erosion of their control over that domain.
On the other hand, the license fees they get from the intranet servers is probably miniscule compared to the license fees they get from all those desktop boxes running Windows+Office, so maybe they really do see this as more good than bad, on the whole. And, of course, they'll still presumably be selling Exchange servers and whatnot.
I don't quite understand the objection. You think we should keep using a seven word phrase instead of a simple single word? That seems...pointless.
I'll grant that the concept isn't necessarily a pleasant one, but it isn't necessarily unpleasant either. And its implications, both fortunate and un-, are shared by that seven word phrase. Unlike "premium", which is definitely used to be misleading, "monetize" seems refreshingly straightforward to me.
I'll admit that the word has unpleasant associations for me, due to SCO's empty claims that they were going to "monetize Linux", but phrasing it another way wouldn't have helped, so I try not to blame the word for the evilness of some who use it. But not everyone trying to make a profit is necessarily evil, at least in my opinion.
On the scale of annoying biz-speak, the word "monetize" doesn't even begin to register for me. I'm really not sure why it tops the list for you.
Slashdot Mirror
In my experience LSD makes you THINK you are having great epiphanies but if you actually record yourself or write them down they aren't very wondrous and usually not even coherent in the morning.
Generally true, but back in late seventies or early eighties, I actually designed and implemented a debugging tool while tripping balls. It was in use throughout the company within a week. It actually came to me in a vision. :)
Of course, when it comes to psychedelics, "You Mileage May Vary" has never been more true. There seem to be no consistent effects from person to person. Even dilated pupils turn out not to be universal (although it's the closest that's been found). Just because I was (at least once) able to direct my hallucinations in a useful direction doesn't mean someone else will.
C# is a great language , Java is a great language , Perl is a great language , C is a great language, Scala is a great language, Lisp is a great language.
You're confusing languages and VMs. Java-the-language is perfectly adequate*; Oracle's JVM is a very dubious beast. Of course, you can always get a native compiler (I have one, though I've never used it), if you really love Java, and don't trust the JVM. Though that won't help you with applets.
I agree with the main thrust of your post: the problem is applets and browsers and trust, not languages, but you seemed to be confusing the matter while trying to clarify, so I thought I'd supply a little real clarification.
* After over a quarter-century as a programmer, I have yet to see a language I would describe as "great". Adequate to the task at hand seems to be about as good as it gets, and even that's more rare than it should be! :)
Using a striping arrangement (or striping with parity)
Ah, I see your mistake. You saw "raid", and assumed he was talking about striping, rather than the more obvious (since he then mentioned "redundancy") mirroring (e.g. RAID1). I'm not sure if that's a case of you having too little knowledge or you assuming too much on his part. I would have said mirroring if I meant mirroring, to avoid the potential for confusion, but I certainly figured he meant RAID1, even though the term "raid" is more commonly associated with striping.
I think it was pretty obvious that he had mirroring in mind, since what he actually said was "using a software raid (redundancy etc)". (Emphasis mine.) That's the only place he mentioned RAID, so I seriously doubt his goal is striping! :)
If you don't trust the provider to keep your data intact, don't use that provider.
That's either a ridiculous statement, or completely off-topic. When it comes to reliability, trust isn't an absolute yes/no thing--it's measured in percentages. And redundancy multiplies reliability, so it's a big win.
There's a trade-off for complexity here, and it's possible to question whether all the extra effort is really worth the potential gains in reliability. (Is it really that important to have eight nines instead of four, or ten instead of five?) But there's nothing wrong with investigating the possibility. And he didn't say anything about price. Or amount of storage. Perhaps he's perfectly willing to pay $10/mo three times over, just for the satisfaction of knowing his data is super available.
For that matter, nobody, no matter how reliable, can guarantee you absolute security. Security is also something you have to measure in percentages (though it's a lot harder to estimate accurately). Encrypting your data gives you an extra layer of protection, even if you think your provider's security is good.
More relevant (since the one you mentioned was covered in the summary) is this: Real World Code Sucks, from a few weeks ago.
There are a lot of reasons why real-world code doesn't resemble the stuff you saw in school. Some are good reasons, some are not. The problem domains in the real world are usually a lot more complex than the ones you encounter in school, which is a good reason. Deadlines and the pressure to make it work, rather than make it right are bad (but unavoidable) ones.
Writing maintainable code is great in theory, but the problem with it is that people maintain it, and the result is usually less maintainable than the original. It's a paradox that should have a name. :)
Anyway, what this definitely has in common with the previous article (the "How can I explain..." one) is that we don't have enough information to judge who's right. Chances are high that both sides have valid points, but it's impossible to be sure from the outside.
There is no ASCII mu. ASCII is a seven-bit encoding which only covers unadorned latin alphabetic characters, arabic digits, and some random punctuation. Even latin1 (aka ISO8859-1) lacks a mu character. I'm not sure what you think you typed, but it definitely wasn't ASCII.
There's also the problem of potential confusion between U+00B5 MICRO SIGN and U+03BC GREEK SMALL LETTER MU (among others), but neither of those is remotely ASCII.
Anyway, yeah, slashdot sucks when it comes to international character support.
Except that the study explicitly showed that population density was not a correlate. Which means that that xkcd, while still amusing, does not seem to be particularly relevant at all.
Well, yes, but many of the people I know who use Macs only do so because you can run vim on a Mac. However, vi itself is about as opposite to the general Mac philosophy as you can imagine--and one of the clearest demonstrations ever that "ease of use" and "ease of learning" are not synonyms.
A better example is "polish" versus "Polish"--not only does the meaning change, but so does the pronunciation!
Though my favorite example of the importance of distinguishing cases is the classic sentence, "Help your Uncle Jack off the horse." WIthout the upper-case, that takes on a whole new meaning! :)
Case matters, and case-insensitive filesystems are one of the stupidest inventions ever.
So then they're fine with the way Windows 8 handles it? Because that's exactly what Microsoft demands of computer manufacturers who want to be certified for Windows 8.
Only on x86. The MS requirement for user-control over UEFI only applies to x86 systems. Arm based systems (phones, pads, etc.) have no such requirement.
But yes, I was surprised and pleased that MS included those requirements, even if it was just for x86, and I'm sure the FSF was as well.
The drivers are not as independent as you think, and system-wide Debian issues are insanely rare--I was a Debian Developer for over a decade, and I only remember one issue that even came close to having the kind of scope that kernel devs see regularly. Furthermore, the kernel is years older than Debian, and, in fact, Debian deliberately looked at (and still looks at) kernel development for ideas on how to manage their system. (And I'm still unconvinced by their elective leadership approach--Democracy has its place, but I'm not sure that "technical lead" is one.)
If you tried pointing at the BSDs, you would have a stronger argument, but the BSDs are, if anything, even more anarchic, with hostile forks happening every time someone loses enough patience with current leadership--and with plenty of assholery-in-charge as well.
Anyway, how the fuck is that an example of him being an asshole? Do you think that anyone who drops an F-bomb is an asshole? You're too fucking sensitive, dude, and I say that with the greatest fucking respect. This is a team that knows each other, usually fairly well, and doesn't stand on formality. Did you even see the part where he says, "I have a stupid trivial complaint"?
Well, speaking as someone who has known one of the founders of the GNU project (Roland McGrath) all his life, and someone who was himself a member of Debian for over a decade, I assure you those are both very different from the kernel. First of all, the GNU project was, for a long time, a Cathedral-style project--in fact, it's the Cathedral in The Cathedral and the Bazaar. Linux is the biggest single bazaar-style project ever. Furthmore, both GNU and Debian are wide-ranging multi-part projects. They are, overall, much bigger than Linux, but Linux is much more of a single thing, while GNU and Debian are huge collections of loosely-related components that mostly operate independently.
When I said Linux was unprecedented, I meant it.
In any case, Linux is not run as an "asshole-in-chief" style project. Linux is rarely an asshole. When he is, it tends to make the front page of Slashdot. That's how rare it is. (Now FreeBSD, on the other hand...) :)
Bottom line, Linus has been in charge of the kernel for a couple of decades now, and his process is working. He doesn't flip out very often, so when he does, every who counts knows that some serious fuckups happened. And anyone who doesn't count (which in this case, almost certainly includes both you and me) can probably go fuck themselves if they don't like it.
Nobody in the world knows for sure how to manage a project like Linux. It is truly unprecedented. But Linus's way is working better than anyone would have expected two decades ago. If you want to second-guess him, feel free to start your own competing project and manage it your way. His way is working better than anything anyone else has ever tried, even if it's not "the best way".
Agreed, especially once the kid has accumulated more than one set, the possibilities open up. My nieces usually start by building whatever they're supposed to build, but once that's done, the pieces go in a bucket with all their other legos, and become the basis for all sorts of random things.
It would take a very bizarre child to not recognize the potential for mashups and personal designs.
Well, you can refactor without fear if you're overoptimistic. And when it comes to writing code, aren't we all overoptimistic? :)
But yes, relying wholly on tests assumes your tests are without flaw, which is about as likely as the code being without flaw in the first place. Still, it's better than the alternative--not relying on tests. :)
- Requirements are messy (even not counting the fact that they change constantly)
- Textbook code is designed to look clean, but often ignores important edge cases for the sake of simplicity. (See previous point.)
- Cleaning up the code may potentially introduce bugs, so once the code gets past QA, it's often considered untouchable until a demonstrable problem is found.
I'm sure there's even more...
(Test-Driven Development (TDD) is supposed to help address that last point, but A) it's not always perfect, and B) it's not universally used.)
The fact that the Weekly World News ceased publication in 2007 could also have something to do with it.
Was that an answer to his first question or his second, or both? I think it works as an answer to both. :)
I think I can field this one. E17 was developed openly. Some people have been using it for years. The stable release is simply that--it's now considered feature-complete and solid enough to be a 1.0 release instead of a 0.x release.
Having a centralized GUI monitor in the NOC is something that's been around since the '90s, if not longer. That still doesn't require GUIs on the server. The monitor system communicates with the servers with something like SNMP (Simple Network Management Protocol), and can usually be heavily customized to run all sorts of scripts on the servers.
Of course, for some guy running a lone server, a system like this is complete overkill. But that's an edge case.
All of our menu bars, status displays, ribbons, etc*, are horizontal bars on the top or bottom of their respective areas.
Apparently, you've never used AfterStep/WindowMaker, etc., where all the desktop widgets go on the right or left. They've been around since before you could get widescreen displays.
Personally, I'm thinking of adding a second column of widgets and swallowed apps on my right-side dock.
The 486 came out in '89. The first public kernel release was in '91. The 386 has basically been obsolete the entire time that Linux has existed.
I actually tried that very first public release when it came out, and I have never run Linux on a 386.
So, as long as they keep supporting the 486, I'm good. Heck, I won't even mind if they drop the 486/SX, and just kept support for the DX. :)
I dunno. There's a big difference between the dreams of controlling the web, which I think MS probably realizes is out of reach, at least for the moment, and the dreams of controlling the office LAN, which still seems to be very much a part of MS's plans.
All the Linux server farms have gotten by without AD just fine, so interoperability there is clearly not crucial, and I doubt we'll see all that many deployments of Samba on the existing farms. It's the IT department and their internal networks that are going to be affected here, and I have a hard time believing that MS is really all that happy about this erosion of their control over that domain.
On the other hand, the license fees they get from the intranet servers is probably miniscule compared to the license fees they get from all those desktop boxes running Windows+Office, so maybe they really do see this as more good than bad, on the whole. And, of course, they'll still presumably be selling Exchange servers and whatnot.
I don't quite understand the objection. You think we should keep using a seven word phrase instead of a simple single word? That seems...pointless.
I'll grant that the concept isn't necessarily a pleasant one, but it isn't necessarily unpleasant either. And its implications, both fortunate and un-, are shared by that seven word phrase. Unlike "premium", which is definitely used to be misleading, "monetize" seems refreshingly straightforward to me.
I'll admit that the word has unpleasant associations for me, due to SCO's empty claims that they were going to "monetize Linux", but phrasing it another way wouldn't have helped, so I try not to blame the word for the evilness of some who use it. But not everyone trying to make a profit is necessarily evil, at least in my opinion.
On the scale of annoying biz-speak, the word "monetize" doesn't even begin to register for me. I'm really not sure why it tops the list for you.
But I know their engineers think it's cool :-).
Hmm, yeah, that part certainly makes sense. :)