Re:easy & dangerous. Like sirens?
on
MySQL FS
·
· Score: 1
WTF? The was closed on preview! Grr, I hate Slash.
Re:easy & dangerous. Like sirens?
on
MySQL FS
·
· Score: 1
Presumably, they just return a failed value. There doesn't seem to be any standard error codes for that type of error, but there's no reason another error code could not be used. Also, don't think exceptions, really - exceptions are cool in Java (I'm guessing that's what you use mostly:) ) but most other languages don't really use them. (I like exceptions better than error return codes, personally. But I have to live with error return codes... *sigh*)
How about:
char buf[] = "foo,bar,bally"; if (write(fd, buf, sizeof(buf)) if (errno==EINVALDATA) { fprintf(STDERR, "Invalid data\n"); } }
The standard error codes (as specified by man 2 write: EBADF, EINVAL, EFAULT, EPIPE, EAGAIN, EINTR, ENOSPC, and EIO) don't really cover that scenario, but any non-zero value from write indicates an error.
My question is how to form a path to a row/column (and are you forming paths to rows or columns?) - would it be something like/db_name/table_name/column_name/value or/db_name/table_name/columns_primary_key?
Before the parent poster gets moderated down by people who didn't read the article, I feel like posing some Job quotes from the article:
Here's Jobs on the experience of buying a computer compared to buying a car: "At least you can go to an auto dealer and test drive a fucking car," the dealers reported him as saying.
On Apple's (AAPL) poor education sales this year: "We fucked up. We fucked up big time."
And when told by dealers that Apple changed a policy (only 3 years ago) of allowing resellers to reprint Apple's ads in local papers, he said, "You're fucking joking?"
Unless he really was a troll... ironic if he was...
Slash actually has two entry boxes: one for the blurb on the front page, and one for the portion that appears on the actual article page. It's quite possible to write a summary for the first page and then have the complete article on the second.
What he should have done is written the summary on the front page portion, copied it onto the article body since people seem to expect that, then an <hr> and then the article.
Re:Cool but a BFT (Big F*SCKING Target)
on
Laser-equipped 747
·
· Score: 1
The thing is, AWACS and JSTARS haven't been used in real air combat scenarios - where the enemy air power equals the friendly air power. AWACS and JSTARS are also very valuable targets - and they require the same infrastructure the original poster described. When winning the war requires taking out one of those 747s, I'll bet you that whoever fired the ICBM would find some method to do it.
All you have to do to put the 747 out of commission is attack it, really - all you have to do is slow the thing down so it can't reach the target and destroy the missile. Engaging the 747 could be enough to prevent it from completing the mission - let alone finishing it. AWACS can turn tail and run if the need arises. If this thing has to retreat, then the city that the original ICBM targetted is toast.
Re:Cool but a BFT (Big F*SCKING Target)
on
Laser-equipped 747
·
· Score: 1
The laser has to stay on target for some duration to do damage (several minutes, apparently - more than enough time for a manuerverable plane to fly a loop and get out of the way). The moving aircraft should be more than enough to compensate for a sustained hit. Especially if the aircraft maintains it's distance and stays behind the laser plane.
And just like AWACS, it's a valuable target - in a real air war, AWACS would be a strategic target - the enemy would fly sorties against AWACS, presumably enough to take out the surrounding guards as well.
Ok, you get in your jet, I'll get into my 747.
Again, I stay over the horizon (out of your LASER range) and fire my AA missiles at you. I don't know the official range of AA missiles, but it's more than enough for me to fly behind you and not actually cross the horizon and be in the line of sight of the laser. And I can do a quick 180 verticle loop and then rotate level and hit the afterburner to get away after the missiles are away.
In reality, the jet would be protected by a squadron of planes - but assuming I could get a lock and fire off two missiles at the 747, counter-measures aside, I should be able to score enough of a hit to disable the craft. (Most counter-measures rely on the craft being smaller and being able to move rapidly away from the counter-measure - I'm not sure how much flares/chaff would help a 747.)
Re:Cool but a BFT (Big F*SCKING Target)
on
Laser-equipped 747
·
· Score: 1
Because the six fast moving sidewinders fired from 100Ms that's locked onto one of the port engines is a fair bit more manueverable than the single IBCM that's heading towards downtown Washington DC.
And jets have this annoying tendency to A) fight back and B) fly evasive patterns.
(Plus, based on the current design, coming in at the tail would be a nice, fun, happy tatic to make actually taking out the enemy plane much more difficult.)
Also, as stated, this would be a high-value target - meaning that you wouldn't launch one plane at the thing, you'd launch several. And these planes would almost definately engage the missle-sweeping 747 beyond visual range, over the horizon. Quickly turning a 747 around (since the nose-mounted laser doesn't have a full 360 of freedom) isn't quite possible - and a high-powered laser is definately a line-of-sight weapon.
Actually, it's a sign of an inferior web browser. Since the document is an HTML document (and I'd assume the MIME type is set correctly, I'd try manually doing the HTTP request via telnet, but I don't really remember how), then the HTML standard demands that lines end in one of the following: ^M only, ^J only, or a ^M^J pair. The original official was ^M^J pairs, and all user agents are supposed to return text fields like the comment text field using ^M^J as the newline character. (As defined in Section 9.3.2 of the HTML 4.01 spec.)
Since a superior alien race would definately have an HTML complaint browser, their browser almost definately won't display the HTML with the extra character on the end. And ^M^J was the standard long before UNIX came around and shortened it to just ^J. (Originally, on teletypes, the ^M would slowly start the carriage back to the beginning, hence "carriage return" and the ^J would then move the paper up a line, hence "new line." This becomes pointless on these fancy monitor thingies, so most modern OSes use just one character.)
The real problem with the lack of a micropayment system is that it isn't widespread yet - there would need to be a whole new infrastructure to deal with it. I believe that Digital did some work on micropayments a while ago, but now they're Compaq, and I believe the work was stopped. (This information is based mostly on a rumor, so take it with a grain of salt.)
We need a new protocol for micropayments - something other than HTTP. Something designed for transactions - ensuring that both the client and server agree that the transaction is complete before it happens. That feature is missing in HTTP. Once you've sent the 200 OK packet, you've assumed the client agrees - the problem comes when the OK message never makes it to the client. The client then hits "stop" and presses the button again - in some cases, resulting in the action being done twice.
Then you have the problem of actually serving a micropayment - where does the money come from? Do you have a company that serves micropayments, where users have to pay for the service? Other problems come if you want to accept multiple forms of currency. I'm sure readers in Europe would just love being forced to open an account somewhere with American dollars. A Web-wide form of "currency" could either help or hinder - or you could simply auto-convert given some official rate from somewhere.
If you actually want to create a working micropayment system, you'll need to create some form of task group to look into it. The answer to the question you asked is that there are both political and technical problems that need solving before such a system can be created. The only way to implement micropayments well is via a brand new infrastructure. And that'll cost money and time.
Wow, which API call tells viruses if the user is an idiot? As far as I know, that was the Love Bug's only significant system requirement.
I'm way too late, but the answer is simple: Set the log to record the User-Agent: header. Presto, a list of all users who read the e-mail, what e-mail client they used, and for most clients, the OS they are running.
This information can be invaluable: grep IE/var/log/httpd/access_log
Presto, a nice list of everyone who accessed using some version of IE (I don't know what Outlook sets the User-Agent to). If you set it up to have a query string with the e-mail address recorded (ie, http://www.example.com/bug.gif?user@example.net - generated through your spam-script) your log suddenly includes the e-mail address too. This is how much information you can record and why this can be a threat - especially coupled with the fact that the most insecure clients download the images without user-option.
Bad analogy - as anyone who finished the Ender's series knows, the ansible was magic! : )
(A brief explanation: about the forth book, somehow the ansible's workings get tied into peoples' "souls" and the explanation becomes this strange pseudo-science type deal that can best be explained as magic - although pseudo-science works too...)
It's primarily the GUI that's causing Mozilla all sorts of problems. Windows GUI is simple to use (compared to X, and I would argue GTK+ too but I haven't used GTK+ enough to pass judgement), and is much, much faster. The simple reason for this is twofold, the first being that Windows GUI apps talk directly with the GUI system through system calls (USER.DLL anyone?) that go straight to the device, while X requires both a netowrk layer and then a user-space layer (although some also have a kernel-space layer). While buggy device drivers under Linux (minus those with kernel-space drivers) usually won't bring the entire system down (stability) this costs speed. Poor Windows drivers can bring the system down, but you don't have the extra layer (speed).
The second problem really isn't a Linux problem, it's poor vendor documentation and Windows-only device drivers. Most manufactorers work hard to create fast, speedy, Windows drivers. Most Linux drivers are reverse-engineered. This costs Linux some speed.
Until someone creates a GUI system under UNIX that doesn't require a network layer, UNIX GUIs will always be slower than Windows GUIs. This network layer is simple overhead, and will always slow down a Linux GUI - even on a loopback device. As computers get faster, it might be less noticable, but the network layer always will slow it down.
Nope - no truth to the rumors. Although you can revive Aeris - as long as you don't mind playing around with either or your save via hex editor or with the Game Shark. Obviously, back up any data first....
I've got a save with Aeris and all her limit breaks - here Ultimate one is pretty cool - it causes the Peerless status on all allys. It's similar to Invincible Moon in FFVIII but more reliable and with a longer effect... Too bad she's not around for any of the tougher enemies...
Actually, I got all Master Materias without using any work-arounds - there are enemies you can steal/mug elixirs from. And yeah, you spend a lot of time bashing those magic pots to do it. But once you master Knights of Round, it's all been worth it:)
Besides, with once you have three Mimes and three (Support)Counters, things become very easy - put Counter-Mime on everyone, have someone cast W-Summon Knights of the Round twice, and then you have an endless loop of Knights of the Round. Makes Emerald WEAPON rather easy - although Ruby is still a challenge.
Besides, the real fun was in playing with the materia... I'll have to load up my save with two Master Materias of each type... (All Weapons defeated too...) Since I have a first-run version, makes SAFER-Sephiroth a piece of cake:)
Dammit, I'm dyslexic - stupid Roman Numerals. And all of FFVI's airship's survive to the end too - No they don't - only one does. All of FF I V's survive to the end.
*I* personally believe that the continent fell on the thing - you walk over a spot on the continent and the airship is directly below, you jump onto it in the end, and when it cracks I believe that they did some shadow thing. Either that or just energy from the statues.
Want a.MOD of the original airship music? (You can also get it in.NSF format.) I could e-mail it...
Actually, I don't remember exactly how the FFVII airship was damaged, it was from either the comet's weirdo energy thing (those red beam things), Holy, something errupting from the crater (that'd be Holy, actually), or the Lifestream. I'm pretty sure it wasn't the Lifestream - I think it was actually Holy errupting up from the crater.
I dunno - the FFVII ending didn't make a whole lot of sense...
Well, when the floating continent FELL on the airship in FFVI (I use the Japanese numbering scheme, since the re-release does) I think it makes sense that the thing was destroyed... besides, the Falcoln was better than Setzer's black balloon anyway.
FFVII's airship survives until the end when basically debris from a comet destroys the thing, but even then, it has some emergency over-ride like thing that allows it to keep functioning.
FFVIII's airship was a spaceship, but FFVIII sucked anyway:)
Actually, FFI's airship wasn't really an Airship-Airship, it used helicopter blades and a magical floater stone which caused it to float - but damn, was it fast! Fastest FF airship to date, I think...
And all of FFVI's airship's survive to the end too... hey, one of them could even make it to the moon! Although that was really a spaceship, the Giant Whale, I guess.
From the article: but being smaller it's a whole lot faster - a fast Solaris JVM implementation!?
The Java byte code really isn't all that slow. In fact, making the VM smaller would actually probably make it slower since you'd be leaving out things like a JIT or any sort of optimization. Generally speaking, there is a compromize between speed and size - large usually is faster (optimized for speed), smaller usually is slower (optimized for size).
The JVM itself is a nice speedy little thing. It's not slow. It's the Abstract Windowing Toolkit (AWT) that's slow! Since almost all Java apps require some form of GUI interaction, and the AWT is the means of graphical interaction, the AWT becomes a signifigant bottleneck. If Sun spent some time on speeding up the AWT, all those pretty graphical Java apps would receive a nice speed boost.
Even with the JIT turned off, Java bytecode alone usually runs at a decent clip. Unfortunately for Java applications, the AWT is very slow - it actually became slower in JDK1.2 and is picking up some speed in JDK1.3 (it hasn't regained it's JDK1.1 speed though).
If anyone wants to read a more indepth benchmark comparing x86 C with Java code, try here.
I didn't find that feature very obvious, maybe because it doesn't work on my computer (so they disabled it for the default book that can be read aloud). I finally after some searching discovered where it says that you can listen to books - but still, as a permission, saying that the book cannot be "read aloud" is a little misleading. Saying something along the lines of:
Read Aloud This book cannot be read aloud using text to speech software
Is tons different than:
Read Aloud This book cannot be read aloud
It sure sounds like they don't want me to read the book aloud to anyone else! They could have made it more clear, and there is only one small paragraph detailing this feature in the online eBook manual. Not entirely a bangup job on Adobe's side either.
Sadly enough, it is 100% REAL. I just downloaded the eBook 2.0 beta software and the (free - money-wise) Alice book (yes, that's right, it's free (monitarily at least) - so you can verify it yourself. The license on the software isn't that bad - one of the few that says you can reverse engineer it in some circumstances, like for interoperability...). The book is available for downloading although you need to have installed the Win/Mac software first. (And the Win version requires a reboot, of course.)
If you want to see my screen shot of the EXACT SAME thing, then check it out. Notice I chose the contents page. Or if you don't believe that, try the Title page. Yes, the period is missing on the Read Aloud part. But it's still listed there.
That screen shot is real - whether they are serious or not is another question.
Heh, I was in that class too. It was sort of cool, playing with the Linux kernel (v2.2.14-SuSE). Although I would rather see in the future the lab being done where you modified a kernel and then ran the OS on a virtual machine. All the projects before the final one took hours that was mostly spent rebooting a fscking due to some stupid little error that halted the kernel. (Oh, that task pointers are a loop? Crap, that's why my scheduler froze the system.) Even if you didn't freeze the machine, you still wound up rebooting to try the new kernel. The last project went quickly because, being a kernel module, you could insert it, test it, and take it back out without rebooting. (That and it was incredibly easy.)
If instead you modified an OS and ran it in a virtual machine, the OS dying in the virtual machine wouldn't need to be fully-rebooted - you just restore the image, patch in the new kernel, and try again. You'd still have to boot, but you'd gain the ability to debug the kernel in the virtual machine with better control than attempting to debug the kernel while running it on the actual machine (which mostly consisted of printk statements to the kernel log). The first assignment was a killer because messing up the scheduler basically meant a reboot followed by a fsck.
Although it was definately cool to learn about the differences between Linux and other OSes and why the Linux scheduler sucks and the Windows one does too but in different ways. (Linux could use preemptive multitasking, where a process that should have the CPU gets it as soon as possible, while Windows needs some work to prevent it from starving processes.) It also gave me a new appreciation for kernel modules and just how cool that technology was. (So, is Linux really a monolithic kernel? The kernel modules put it into this nice limbo between monolithic and micro.)
And String is still a bit confusing in that it's an object you can write as a literal, and isn't mutable.
There's a really dumb reason for that - Java internals have this nasty habit of deciding to hold onto the reference of a String - I suppose it saves memory since you have two references to a string and not two instances.
Same reason Color objects are immutable.
Well, for every possible tuple I might want, yes. Do I really want a directory full of Custard$ResultFromABCMethod.class, Custard$ResultFromXYZMethod.class, Custard$ResultFromABCButWithAnExtraBoolean.class? I'm more likely to kludge it, I think, using private member fields as result passing.
For the finished result, try a jar file. Nice, compact, no little files all over the harddrive. Java 1.2 supports compression in them too! (A jar file is a glorified.zip file.)
Um, BTW, how many tuples do you ever need to return? Ever consider trying to generalize them into an object? You shouldn't need thousands of tuples - a generalized class should do.
I wanted two timers to call back my class at different intervals. Obviously they'd both call the same method, so I wouldn't be able to tell between them without writing extra glue classes.
Inner classes, inner classes. They're all over the place, often used for exactly that purpose. Especially because an inner class has full access to all it's parents fields (including private!).
Well, the first few exceptions I stumbled across were MalformedURLException and InterruptedException.
Oh yeah. Those. Almost every time I have ever run across them, I have found myself trapping them and ignoring them. (InterruptedException especially because often it has no use at all.)
HOWEVER - the point stands that you should be forced to plan for them - Java forces people to be ready to trap an exception - so you can't skip an exception. Often times its annoying but it forces better code design. Once you get used to Java exceptions you'll find them quite useful - I couldn't program without them.
Most exceptions aren't RuntimeExceptions for exactly the reason that you shouldn't be tempted to ignore them. For example, an IOException really shouldn't be ignored. And try{}catch() blocks don't really add any overhead, so ignoring useless (like the MalformedULRException) exceptions is OK. (InterruptedExceptions shouldn't crash your program - I often use them to wake up sleeping threads (sorta - it does something every x seconds, and then needs to be woken up to clean up or whatever).)
Slashdot Mirror
WTF? The was closed on preview! Grr, I hate Slash.
How about:
char buf[] = "foo,bar,bally";
if (write(fd, buf, sizeof(buf))
if (errno==EINVALDATA) {
fprintf(STDERR, "Invalid data\n");
}
}
The standard error codes (as specified by man 2 write: EBADF, EINVAL, EFAULT, EPIPE, EAGAIN, EINTR, ENOSPC, and EIO) don't really cover that scenario, but any non-zero value from write indicates an error.
My question is how to form a path to a row/column (and are you forming paths to rows or columns?) - would it be something like /db_name/table_name/column_name/value or /db_name/table_name/columns_primary_key?
Here's Jobs on the experience of buying a computer compared to buying a car: "At least you can go to an auto dealer and test drive a fucking car," the dealers reported him as saying.
On Apple's (AAPL) poor education sales this year: "We fucked up. We fucked up big time."
And when told by dealers that Apple changed a policy (only 3 years ago) of allowing resellers to reprint Apple's ads in local papers, he said, "You're fucking joking?"
Unless he really was a troll... ironic if he was...
They were also impressed by his incredible potty mouth.
Every sentence he uttered -- every single one -- contained an expletive.
Sorry, I just found that funny.
What he should have done is written the summary on the front page portion, copied it onto the article body since people seem to expect that, then an <hr> and then the article.
All you have to do to put the 747 out of commission is attack it, really - all you have to do is slow the thing down so it can't reach the target and destroy the missile. Engaging the 747 could be enough to prevent it from completing the mission - let alone finishing it. AWACS can turn tail and run if the need arises. If this thing has to retreat, then the city that the original ICBM targetted is toast.
And just like AWACS, it's a valuable target - in a real air war, AWACS would be a strategic target - the enemy would fly sorties against AWACS, presumably enough to take out the surrounding guards as well.
Ok, you get in your jet, I'll get into my 747.
Again, I stay over the horizon (out of your LASER range) and fire my AA missiles at you. I don't know the official range of AA missiles, but it's more than enough for me to fly behind you and not actually cross the horizon and be in the line of sight of the laser. And I can do a quick 180 verticle loop and then rotate level and hit the afterburner to get away after the missiles are away.
In reality, the jet would be protected by a squadron of planes - but assuming I could get a lock and fire off two missiles at the 747, counter-measures aside, I should be able to score enough of a hit to disable the craft. (Most counter-measures rely on the craft being smaller and being able to move rapidly away from the counter-measure - I'm not sure how much flares/chaff would help a 747.)
And jets have this annoying tendency to A) fight back and B) fly evasive patterns.
(Plus, based on the current design, coming in at the tail would be a nice, fun, happy tatic to make actually taking out the enemy plane much more difficult.)
Also, as stated, this would be a high-value target - meaning that you wouldn't launch one plane at the thing, you'd launch several. And these planes would almost definately engage the missle-sweeping 747 beyond visual range, over the horizon. Quickly turning a 747 around (since the nose-mounted laser doesn't have a full 360 of freedom) isn't quite possible - and a high-powered laser is definately a line-of-sight weapon.
Since a superior alien race would definately have an HTML complaint browser, their browser almost definately won't display the HTML with the extra character on the end. And ^M^J was the standard long before UNIX came around and shortened it to just ^J. (Originally, on teletypes, the ^M would slowly start the carriage back to the beginning, hence "carriage return" and the ^J would then move the paper up a line, hence "new line." This becomes pointless on these fancy monitor thingies, so most modern OSes use just one character.)
We need a new protocol for micropayments - something other than HTTP. Something designed for transactions - ensuring that both the client and server agree that the transaction is complete before it happens. That feature is missing in HTTP. Once you've sent the 200 OK packet, you've assumed the client agrees - the problem comes when the OK message never makes it to the client. The client then hits "stop" and presses the button again - in some cases, resulting in the action being done twice.
Then you have the problem of actually serving a micropayment - where does the money come from? Do you have a company that serves micropayments, where users have to pay for the service? Other problems come if you want to accept multiple forms of currency. I'm sure readers in Europe would just love being forced to open an account somewhere with American dollars. A Web-wide form of "currency" could either help or hinder - or you could simply auto-convert given some official rate from somewhere.
If you actually want to create a working micropayment system, you'll need to create some form of task group to look into it. The answer to the question you asked is that there are both political and technical problems that need solving before such a system can be created. The only way to implement micropayments well is via a brand new infrastructure. And that'll cost money and time.
I'm way too late, but the answer is simple: Set the log to record the User-Agent: header. Presto, a list of all users who read the e-mail, what e-mail client they used, and for most clients, the OS they are running.
This information can be invaluable: /var/log/httpd/access_log
grep IE
Presto, a nice list of everyone who accessed using some version of IE (I don't know what Outlook sets the User-Agent to). If you set it up to have a query string with the e-mail address recorded (ie, http://www.example.com/bug.gif?user@example.net - generated through your spam-script) your log suddenly includes the e-mail address too. This is how much information you can record and why this can be a threat - especially coupled with the fact that the most insecure clients download the images without user-option.
(A brief explanation: about the forth book, somehow the ansible's workings get tied into peoples' "souls" and the explanation becomes this strange pseudo-science type deal that can best be explained as magic - although pseudo-science works too...)
The second problem really isn't a Linux problem, it's poor vendor documentation and Windows-only device drivers. Most manufactorers work hard to create fast, speedy, Windows drivers. Most Linux drivers are reverse-engineered. This costs Linux some speed.
Until someone creates a GUI system under UNIX that doesn't require a network layer, UNIX GUIs will always be slower than Windows GUIs. This network layer is simple overhead, and will always slow down a Linux GUI - even on a loopback device. As computers get faster, it might be less noticable, but the network layer always will slow it down.
They do that so you can do stuff like the following:
SomeObject so = (SomeObject) stack.push(new SomeObject());
((SomeObject)stack.push(so)).someMethod();
Exactly how useful that is aside, that's the reasoning.
I've got a save with Aeris and all her limit breaks - here Ultimate one is pretty cool - it causes the Peerless status on all allys. It's similar to Invincible Moon in FFVIII but more reliable and with a longer effect... Too bad she's not around for any of the tougher enemies...
Actually, I got all Master Materias without using any work-arounds - there are enemies you can steal/mug elixirs from. And yeah, you spend a lot of time bashing those magic pots to do it. But once you master Knights of Round, it's all been worth it :)
Besides, with once you have three Mimes and three (Support)Counters, things become very easy - put Counter-Mime on everyone, have someone cast W-Summon Knights of the Round twice, and then you have an endless loop of Knights of the Round. Makes Emerald WEAPON rather easy - although Ruby is still a challenge.
Besides, the real fun was in playing with the materia... I'll have to load up my save with two Master Materias of each type... (All Weapons defeated too...) Since I have a first-run version, makes SAFER-Sephiroth a piece of cake :)
Dammit, I'm dyslexic - stupid Roman Numerals. And all of FFVI's airship's survive to the end too - No they don't - only one does. All of FF I V's survive to the end.
Want a .MOD of the original airship music? (You can also get it in .NSF format.) I could e-mail it...
Actually, I don't remember exactly how the FFVII airship was damaged, it was from either the comet's weirdo energy thing (those red beam things), Holy, something errupting from the crater (that'd be Holy, actually), or the Lifestream. I'm pretty sure it wasn't the Lifestream - I think it was actually Holy errupting up from the crater.
I dunno - the FFVII ending didn't make a whole lot of sense...
FFVII's airship survives until the end when basically debris from a comet destroys the thing, but even then, it has some emergency over-ride like thing that allows it to keep functioning.
FFVIII's airship was a spaceship, but FFVIII sucked anyway :)
Actually, FFI's airship wasn't really an Airship-Airship, it used helicopter blades and a magical floater stone which caused it to float - but damn, was it fast! Fastest FF airship to date, I think...
And all of FFVI's airship's survive to the end too... hey, one of them could even make it to the moon! Although that was really a spaceship, the Giant Whale, I guess.
I think the original poster knew that is was a PSX he was talking about. He can't find a PSX let alone a PS2. Number 2 may or may not stand.
The Java byte code really isn't all that slow. In fact, making the VM smaller would actually probably make it slower since you'd be leaving out things like a JIT or any sort of optimization. Generally speaking, there is a compromize between speed and size - large usually is faster (optimized for speed), smaller usually is slower (optimized for size).
The JVM itself is a nice speedy little thing. It's not slow. It's the Abstract Windowing Toolkit (AWT) that's slow! Since almost all Java apps require some form of GUI interaction, and the AWT is the means of graphical interaction, the AWT becomes a signifigant bottleneck. If Sun spent some time on speeding up the AWT, all those pretty graphical Java apps would receive a nice speed boost.
Even with the JIT turned off, Java bytecode alone usually runs at a decent clip. Unfortunately for Java applications, the AWT is very slow - it actually became slower in JDK1.2 and is picking up some speed in JDK1.3 (it hasn't regained it's JDK1.1 speed though).
If anyone wants to read a more indepth benchmark comparing x86 C with Java code, try here.
Is tons different than:
It sure sounds like they don't want me to read the book aloud to anyone else! They could have made it more clear, and there is only one small paragraph detailing this feature in the online eBook manual. Not entirely a bangup job on Adobe's side either.
If you want to see my screen shot of the EXACT SAME thing, then check it out. Notice I chose the contents page. Or if you don't believe that, try the Title page. Yes, the period is missing on the Read Aloud part. But it's still listed there.
That screen shot is real - whether they are serious or not is another question.
If instead you modified an OS and ran it in a virtual machine, the OS dying in the virtual machine wouldn't need to be fully-rebooted - you just restore the image, patch in the new kernel, and try again. You'd still have to boot, but you'd gain the ability to debug the kernel in the virtual machine with better control than attempting to debug the kernel while running it on the actual machine (which mostly consisted of printk statements to the kernel log). The first assignment was a killer because messing up the scheduler basically meant a reboot followed by a fsck.
Although it was definately cool to learn about the differences between Linux and other OSes and why the Linux scheduler sucks and the Windows one does too but in different ways. (Linux could use preemptive multitasking, where a process that should have the CPU gets it as soon as possible, while Windows needs some work to prevent it from starving processes.) It also gave me a new appreciation for kernel modules and just how cool that technology was. (So, is Linux really a monolithic kernel? The kernel modules put it into this nice limbo between monolithic and micro.)
There's a really dumb reason for that - Java internals have this nasty habit of deciding to hold onto the reference of a String - I suppose it saves memory since you have two references to a string and not two instances.
Same reason Color objects are immutable.
Well, for every possible tuple I might want, yes. Do I really want a directory full of Custard$ResultFromABCMethod.class, Custard$ResultFromXYZMethod.class, Custard$ResultFromABCButWithAnExtraBoolean.class? I'm more likely to kludge it, I think, using private member fields as result passing.
For the finished result, try a jar file. Nice, compact, no little files all over the harddrive. Java 1.2 supports compression in them too! (A jar file is a glorified .zip file.)
Um, BTW, how many tuples do you ever need to return? Ever consider trying to generalize them into an object? You shouldn't need thousands of tuples - a generalized class should do.
I wanted two timers to call back my class at different intervals. Obviously they'd both call the same method, so I wouldn't be able to tell between them without writing extra glue classes.
Inner classes, inner classes. They're all over the place, often used for exactly that purpose. Especially because an inner class has full access to all it's parents fields (including private!).
Well, the first few exceptions I stumbled across were MalformedURLException and InterruptedException.
Oh yeah. Those. Almost every time I have ever run across them, I have found myself trapping them and ignoring them. (InterruptedException especially because often it has no use at all.)
HOWEVER - the point stands that you should be forced to plan for them - Java forces people to be ready to trap an exception - so you can't skip an exception. Often times its annoying but it forces better code design. Once you get used to Java exceptions you'll find them quite useful - I couldn't program without them.
Most exceptions aren't RuntimeExceptions for exactly the reason that you shouldn't be tempted to ignore them. For example, an IOException really shouldn't be ignored. And try{}catch() blocks don't really add any overhead, so ignoring useless (like the MalformedULRException) exceptions is OK. (InterruptedExceptions shouldn't crash your program - I often use them to wake up sleeping threads (sorta - it does something every x seconds, and then needs to be woken up to clean up or whatever).)