The only thing that series like the Jetsons and the Flintstones hammer into your brain is that it is OK to act like a cowering sack-of-shit, because you'll always have your loving family to cover for you, and if you don't, well, GET ONE!
As I recall, memory use balloons rather quickly no matter what you do. Worse, it never really comes down again. There was also some discussion at the time (Swing has "built in" memory leaks); don't know if that is still pertinent.
Performance is adequate, but memory management -- oh my god. Check out Tube, a portable Hotline client I wrote last year. Uses anywhere upwards from 19MB of memory. The "official" client needs less than 1MB!
Re:This could be bad news for manned space travel.
on
Life On Mars: ALH84001
·
· Score: 1
It's illogical to presume that eons of isolated life in the barren Martian atmosphere constitute any kind of preparation for the excessively hostile environment that is our bodies.
The biggest problem with Java is not performance but memory use. A Hotline client I have written uses anywhere from 19MB up to 40MB of memory -- too much. And what good is garbage collection if Swing leaks references like NNTP drops articles?
Also, the usefulness of Java as an application programming language (Java on the desktop) is severely hindered by the fact that Sun hasn't solved the packaging / delivery problem; that remains a matter of platform dependant conventions and idiosyncracies, only now you have the added burden of catering to the requirements of some abstract "Java platform" layer.
1) I didn't write a compiler, I was just using X as an example.
That's the point. You didn't write a compiler. Did you make any other significant progress towards your stated vision of a public domain operating system?
2) if you didn't release the source, sold it, that would be fine. It's called FREEDOM.
Is it my ''FREEDOM'' to take your work and claim the credit?
If it's not Public domain, it's not free as in speech. Neither is the copyright. Learn the difference.
I wrote compiler X. Big piece of software was written using compiler X. Should I get credit? No!
Enlighten us. Exactly which compiler did you write?
The GNU is fine and dandy, but..Credit should only be given where credit is due.
And that is why RMS takes credit.
It seems that RMS likes to take credit for any piece of software written under the GPL/GNU. I wish someone would create a "public domain" operating system.
So why don't you? I'm sure you won't mind if I take your public domain operating system, change one line, and claim it as my own. In fact, you probably wouldn't even know it if I did that, seeing how I would be under no obligation to release the source.
A way-cool Konami shoot-em-up from the early eighties. The great thing about this game is the way the levels were architected; not that pseudo-AI crap we have now, but beautiful compositions emerging from rigid determinism.
Elite
The classic space trader. You play this once -- and never really stop. I haven't played this one in years (last time I played it was on an emulator), but still consider myself "in-game". Somewhere at my parents' house there has to be a savedisk with several days of playing time logged.
Driver
Just fucking brilliant, except for the last level, which is shite. The atmosphere is so engrossing and the controls so perfectly balanced that I regularly fire this game up just for the driving.
I suppose that a great game is one you can get really good at -- arfully good, so you reach the point where you're no longer playing the game, but rather playing with the game.
There is something about the idea of severing the link between representation and meaning (Eidola, XML,...) that seems to suggest the existence of a ``private language'' -- something Wittgenstein has devised a compelling counterargument against.
Is it really possible to separate representation from meaning without losing the meaning?
Well, to each his own, but aren't Windows users also the people who dedicate all their screen real estate to a single application?
I'm very happy with emacs and a terminal window. I've worked with some of the best IDE's of their time, too -- MPW, CodeWarrior and Think C on Macintosh. They were nice. Nowhere near as stable and mature as emacs, bash and make.
As for debugging, I have become convinced that the best way to find bugs in code is to read it.
That said, if Komodo helps to increase the attractiveness of Linux as a development platform, that is of course cause for celebration.
However, perhaps those particular FPEs were simply incompetent, and good FPEs make their decisions in a more objective fashion.
Perhaps there are no objective criteria. They cannot even seem to agree on the number of minutae that should match.
But hey, what do I know. You got me curious, though. Maybe a lack of imagination on my part, but how would a test like the one you're proposing be able to verify the methods used by FPE's?
I still don't see what such a test would contribute.
What the article questions is the science behind the method used by FPE's.
According to the article, what happens is that FPE's get a (partial, smudged) fingerprint impression and rely on their experience and intuition to determine whether or not the amount of similarities found is sufficient for identification. When the FBI tells them what to look for, suddenly their judgment sways in the other direction.
This has very little to do with the extent to which known fingerprint impressions match eachother.
That is all very interesting, but besides the point of the article, which questions the science behind the FPE's claim that any two impressions of a fingerprint can be reliably matched.
The reason why this science is questioned is because the FPE's take overlapping, smudged, partial impressions, then rely primarily on their their experience and intuition to determine how great the likeness between the impression and the known fingerprint should be.
This is not about what kind of detail is required to distinguish any two fingerprints -- it is about whether the impressions of fingerprints obtained from a crime scene (that is, smudged, partial, etcetera) can reveal such detail.
You are missing the point. Such tests have been performed, just scan the article for "50K vs. 50K".
The point is not whether fingerprints are unique -- the point is how many fingerprints match any particular (low-detail, smudged, partial) impression of a fingerprint.
The question is not whether fingerprints are globally unique -- as the article points out, given enough detail, they most certainly are, like all natural things.
The question is whether any two fingerprints differ enough for a smudged, low-detail, partial impression of a fingerprint to reliably match the one and not the other.
That is where the science ends and the craftsmanship begins.
Who is the intended audience of the i-Opener? I'll tell you: Those with low-incomes and limited technical background. The elderly; people of color; folks in rural areas.
I'll tell you what the intended audience of the i-Opener is -- people with too little time on their hands and money to burn on net access charges.
You act as if Internet access is some sort of manna from heaven. Just goes to show your bias I guess.
The only thing that series like the Jetsons and the Flintstones hammer into your brain is that it is OK to act like a cowering sack-of-shit, because you'll always have your loving family to cover for you, and if you don't, well, GET ONE!
Yeah, as if Gtk and X are such paragons of speed and finesse.
Typing R is your idea of "wrestling with the OS"??
I love you and want to have your baby.
Probably the journalist screwing up.
Where's the benefit in having to memorize "idltld://slash.dot" versus having to memorize "slashdot.org"?
As I recall, memory use balloons rather quickly no matter what you do. Worse, it never really comes down again. There was also some discussion at the time (Swing has "built in" memory leaks); don't know if that is still pertinent.
Performance is adequate, but memory management -- oh my god. Check out Tube, a portable Hotline client I wrote last year. Uses anywhere upwards from 19MB of memory. The "official" client needs less than 1MB!
It's illogical to presume that eons of isolated life in the barren Martian atmosphere constitute any kind of preparation for the excessively hostile environment that is our bodies.
Yes, well, that you are tired is all too obvious.
Also, the usefulness of Java as an application programming language (Java on the desktop) is severely hindered by the fact that Sun hasn't solved the packaging / delivery problem; that remains a matter of platform dependant conventions and idiosyncracies, only now you have the added burden of catering to the requirements of some abstract "Java platform" layer.
Guess it's back to C for me.
- Nemesis
- A way-cool Konami shoot-em-up from the early eighties. The great thing about this game is the way the levels were architected; not that pseudo-AI crap we have now, but beautiful compositions emerging from rigid determinism.
- Elite
- The classic space trader. You play this once -- and never really stop. I haven't played this one in years (last time I played it was on an emulator), but still consider myself "in-game". Somewhere at my parents' house there has to be a savedisk with several days of playing time logged.
- Driver
- Just fucking brilliant, except for the last level, which is shite. The atmosphere is so engrossing and the controls so perfectly balanced that I regularly fire this game up just for the driving.
I suppose that a great game is one you can get really good at -- arfully good, so you reach the point where you're no longer playing the game, but rather playing with the game.Check out AppleScript ... It even allows dialects.
Is it really possible to separate representation from meaning without losing the meaning?
Well, to each his own, but aren't Windows users also the people who dedicate all their screen real estate to a single application?
I'm very happy with emacs and a terminal window. I've worked with some of the best IDE's of their time, too -- MPW, CodeWarrior and Think C on Macintosh. They were nice. Nowhere near as stable and mature as emacs, bash and make.
As for debugging, I have become convinced that the best way to find bugs in code is to read it.
That said, if Komodo helps to increase the attractiveness of Linux as a development platform, that is of course cause for celebration.
However, perhaps those particular FPEs were simply incompetent, and good FPEs make their decisions in a more objective fashion.
Perhaps there are no objective criteria. They cannot even seem to agree on the number of minutae that should match.
But hey, what do I know. You got me curious, though. Maybe a lack of imagination on my part, but how would a test like the one you're proposing be able to verify the methods used by FPE's?
I still don't see what such a test would contribute.
What the article questions is the science behind the method used by FPE's.
According to the article, what happens is that FPE's get a (partial, smudged) fingerprint impression and rely on their experience and intuition to determine whether or not the amount of similarities found is sufficient for identification. When the FBI tells them what to look for, suddenly their judgment sways in the other direction.
This has very little to do with the extent to which known fingerprint impressions match eachother.
That is all very interesting, but besides the point of the article, which questions the science behind the FPE's claim that any two impressions of a fingerprint can be reliably matched.
The reason why this science is questioned is because the FPE's take overlapping, smudged, partial impressions, then rely primarily on their their experience and intuition to determine how great the likeness between the impression and the known fingerprint should be.
This is not about what kind of detail is required to distinguish any two fingerprints -- it is about whether the impressions of fingerprints obtained from a crime scene (that is, smudged, partial, etcetera) can reveal such detail.
You are missing the point. Such tests have been performed, just scan the article for "50K vs. 50K".
The point is not whether fingerprints are unique -- the point is how many fingerprints match any particular (low-detail, smudged, partial) impression of a fingerprint.
The question is not whether fingerprints are globally unique -- as the article points out, given enough detail, they most certainly are, like all natural things.
The question is whether any two fingerprints differ enough for a smudged, low-detail, partial impression of a fingerprint to reliably match the one and not the other.
That is where the science ends and the craftsmanship begins.
What a pathetic piece of shit.
I'll tell you what the intended audience of the i-Opener is -- people with too little time on their hands and money to burn on net access charges.
You act as if Internet access is some sort of manna from heaven. Just goes to show your bias I guess.