Why did Google wait ten days before notifying OpenSSL? (even if they didn't trust OpenSSL to handle it responsibly, it couldn't have taken ten days for Google to patch their systems)
Given that the entire world is already divided
between people who believe the conspiracy theories circulating
about Google and people who love Google
unconditionally, I doubt they really care too
much about appearances -- people are going
to think whatever they want.
The original Turbo Pascal fit comfortably on a single 360K floppy, with space left over for DOS and all the source code you were likely to write. The IDE included everything you'd want (including an editor that would occasionally scramble files beyond recognition -- but in 1983, that was par for the course on PCs anyway) and nothing you didn't. It was a triumph of interface engineering, given the
resources it had to work with (even today, I'd prefer it to most things).
Kudos to the people who built the original
Turbo Pascal, wherever they are.
It sounds like this "Pascal" is quite extended compared to the original. That's a nice start, but how does it measure up in terms of features to, say, Modula-3? Pascal faded into obscurity everywhere twenty years ago (except for a dwindling number of intro CS classes). What are people planning to do with this? Is it more than retro chic?
I wrote that ML was popular with language weenies, not that it has no use beyond academia or in industrial applications. You act as though
"language weenies" is a derogatory term, instead of a term that means "people who deeply care about programming languages." I guess you're not a weenie.
Ok, let's try java.sun.com.
The JVM, the libraries, JINI, JNI,... what exactly is missing? (JCP is the Java Community Process, which isn't a spec.)
Re:"blessing" doesn't matter
on
Open source Java?
·
· Score: 3, Insightful
Whatever the specific reasons, it's a failure of Java as a general-purpose, standard programming language.
Utter nonsense. Let's count the number of distinct implementations of Perl, Tcl, Ruby, Visual Basic...
Languages that are reimplemented frequently tend to be small, simple and appeal to language weenies (scheme, *ML) and/or there's money to be made.
The specs for Java have always been completely open. Anyone can reimplement it. The only restriction is that you can't call it Java unless it meets the spec (and proving that it
meets the spec is, quite understandably, nontrivial because Java is a large, complex language).
If you like Java but want to change a few things, you're even free to do that, as long as you call it something else, like C#.
and will all come travel to it at some point in their illustrious time-traveling careers.
If I had an illustrious time-traveling career, I'd probably be able to think of a lot of better places to be than hanging around an MIT courtyard. Unless the yet-to-be-discovered laws of temporal travel includes an unfortunate law for the conservation of boredom, of course.
The wikkipedia article you reference says that child porn was legal and normal many places until the 80's or so. That still doesn't make it right...
In any case, this article is about the interaction of child porn and the internet -- people behave differently when they're online than they would ordinarily, unsurprisingly. Whether or not child porn is OK in and of itself is a separate debate.
This is a common problem for protocol-oriented tools of this type, at least if I correctly guess what they're thinking...
Such tools are useful iff their interface is rigidly defined. If it starts diverging into a dozen things that look similar but aren't entirely compatible, nobody will use any of them. If, on the other hand, the system is reasonably good at the start, the probability of major forks is reduced. So sometimes it's useful to keep such projects "closed" until it's stable and complete.
At least, I have heard such arguments made in the past. The other alternative is that the code is such an embarassing mess that they don't want anyone to see it -- I've heard that argument made as well (heck, I've got code I plan to release someday myself, as soon as I get around to adequately commenting it...).
Is this a testament to how far the Pentium Mobile architecture has come, or a sad comment on the clockspeed-pushing design of the Pentium 4?"
What about "both"?
Or, of course, as the parent points out, perhaps the bottleneck is somewhere completely different. Maybe the processor speed is less important than something else (gasp!).
Personally, I'm much more excited by increases in network, disk and bus bandwidth than CPU. I don't spend much time waiting for my CPU; I spend time waiting for data to get to my CPU. YMMV.
As for the state of the art, for the last 20 years there was no compelling need for powerful data organising software, because there was little data on most consumer machines.
There's been a heck of a lot of data that needs to be organized on non-"consumer" machines, however! The amount of data you're talking about should be measured in instances, not megabytes. The fact that a digital photo is more than a thousand times larger than an invoice or a patient record or what have you doesn't make it more difficult to manage -- it just makes the hard drive manufacturers happier.
Very few people have a million photos they need to manage. Very few moderate-sized businesses have fewer than a million records they need to organized in a bunch of different ways.
A lot of people are probably googling for "Gwen Summers" right now...
Seriously, what you've described is the basic problem addressed by any information management system. The fact that it involves photos or video is a bit of red herring. I used programs written in DBaseII to solve this kind of problem (for a vastly different domain...) twenty years ago. I find it hard to believe that the state of the art hasn't progressed until the Picasa showed up.
Every few years the notion of extensible languages pops up. It always sounds nice, but nobody can quite figure out how to make all the nitty gritty details work properly. Look at Dylan -- compare the original goals (astonishing) with what actually got done (interesting but hardly revolutionary). I think that the problem is that once you've extended the language, nobody can remember how it works any more.
At least most of these languages had the decency to look like something palatable. (It'll be a cold day in hell before any hacker I know voluntarily spends all day looking at XML. XML is for machines, not for humans.)
Slashdot Mirror
Why did Google wait ten days before notifying OpenSSL? (even if they didn't trust OpenSSL to handle it responsibly, it couldn't have taken ten days for Google to patch their systems)
Given that the entire world is already divided between people who believe the conspiracy theories circulating about Google and people who love Google unconditionally, I doubt they really care too much about appearances -- people are going to think whatever they want.
More likely this is to keep them out of court.
Give me a moment, and I'm sure I'll think of one.
What, have you been living in a cave for the last six years, or something?
I'm afraid that the only way you're going to see something new come out of Hollywood is to pull a Rip Van Winkle.
At least this is just a remake. Our kids are doomed to a remake of this remake.
The original Turbo Pascal fit comfortably on a single 360K floppy, with space left over for DOS and all the source code you were likely to write. The IDE included everything you'd want (including an editor that would occasionally scramble files beyond recognition -- but in 1983, that was par for the course on PCs anyway) and nothing you didn't. It was a triumph of interface engineering, given the resources it had to work with (even today, I'd prefer it to most things).
Kudos to the people who built the original Turbo Pascal, wherever they are.
Ok, let's try java.sun.com. The JVM, the libraries, JINI, JNI, ... what exactly is missing? (JCP is the Java Community Process, which isn't a spec.)
Utter nonsense. Let's count the number of distinct implementations of Perl, Tcl, Ruby, Visual Basic...
Languages that are reimplemented frequently tend to be small, simple and appeal to language weenies (scheme, *ML) and/or there's money to be made.
The specs for Java have always been completely open. Anyone can reimplement it. The only restriction is that you can't call it Java unless it meets the spec (and proving that it meets the spec is, quite understandably, nontrivial because Java is a large, complex language).
If you like Java but want to change a few things, you're even free to do that, as long as you call it something else, like C#.
It's a bit unfair to start calling something vaporware two months before the scheduled release.
(I don't work on Solaris/OpenSolaris, so I have no special knowledge about the project, except that I know people are working are working on it.)
If I had an illustrious time-traveling career, I'd probably be able to think of a lot of better places to be than hanging around an MIT courtyard. Unless the yet-to-be-discovered laws of temporal travel includes an unfortunate law for the conservation of boredom, of course.
This is just a tiny step to "Hey, we're rich. So screw you!"
You should trademark dupernova asap because I have a feeling it's going to be a very popular word around slashdot.
> Sad to tell you this, ... Bush is going to be the Reagan of the 21st century.
Glad to see that the two of you agree on something.
In any case, this article is about the interaction of child porn and the internet -- people behave differently when they're online than they would ordinarily, unsurprisingly. Whether or not child porn is OK in and of itself is a separate debate.
Such tools are useful iff their interface is rigidly defined. If it starts diverging into a dozen things that look similar but aren't entirely compatible, nobody will use any of them. If, on the other hand, the system is reasonably good at the start, the probability of major forks is reduced. So sometimes it's useful to keep such projects "closed" until it's stable and complete.
At least, I have heard such arguments made in the past. The other alternative is that the code is such an embarassing mess that they don't want anyone to see it -- I've heard that argument made as well (heck, I've got code I plan to release someday myself, as soon as I get around to adequately commenting it...).
What about "both"?
Or, of course, as the parent points out, perhaps the bottleneck is somewhere completely different. Maybe the processor speed is less important than something else (gasp!).
Personally, I'm much more excited by increases in network, disk and bus bandwidth than CPU. I don't spend much time waiting for my CPU; I spend time waiting for data to get to my CPU. YMMV.
There's been a heck of a lot of data that needs to be organized on non-"consumer" machines, however! The amount of data you're talking about should be measured in instances, not megabytes. The fact that a digital photo is more than a thousand times larger than an invoice or a patient record or what have you doesn't make it more difficult to manage -- it just makes the hard drive manufacturers happier.
Very few people have a million photos they need to manage. Very few moderate-sized businesses have fewer than a million records they need to organized in a bunch of different ways.
It's not the data management -- it's the GUI.
Seriously, what you've described is the basic problem addressed by any information management system. The fact that it involves photos or video is a bit of red herring. I used programs written in DBaseII to solve this kind of problem (for a vastly different domain...) twenty years ago. I find it hard to believe that the state of the art hasn't progressed until the Picasa showed up.
At least most of these languages had the decency to look like something palatable. (It'll be a cold day in hell before any hacker I know voluntarily spends all day looking at XML. XML is for machines, not for humans.)
Imagine if this amount of slack could be used for good...