> 1) You can make your own java compiler. > 2) You can make your own JVM. > 3) You can make your own libraries. > 4) Your java code can be open source.
All these things are true, but the one thing you can't do freely is call any of these things "Java(tm)". That requires having your product pass compliance testing and be certified *by Sun*. The compliance kits are not free (in either sense) and the certification process has a price tag attached as well.
This may not seem like a big deal to the individual user or developer, but when dealing with the corporate world you're nobody unless you have that squiggly coffee-cup logo and the "(tm)". The end result is that if you want to play the Java game, you have to play (and pay) by Sun's rules.
> another Sci Fi series we get to see canceled prematurely
Not necessarily. It could turn out to be craptacular. That pretty much ensures that it'll run for years, cranking out episode after episode, each lamer than the last. Then comes an eternity of syndicated reruns. Maybe even spin-offs!
The truly sad thing is that most of us would keep watching it anyway.
Great idea. All they'd need then is some sort of terabyte backup system. Do you recommend CDs, DVDs or tape?
This keeps coming up again and again. No matter how cheap HDs get, they just don't have the durability, portability, or lifetime of "real" offline storage. Sadly, backup technology just isn't keeping up with HD capacities. When >1GB drives first came out, you could get 20GB tapes. Now that we've got 100GB drives, the world needs a TB archive media.
> What is the benefit when the applicable distance is so short?
The first thing that comes to mind is wireless heads-up displays for wearables. Some bogus math:
1024x768 * 32bit * 80Hz = ~2Gb/s
Throw in some compression and other cleverness, and you should have no trouble fitting it in the 500Mb/s they mention. Enjoy streaming digital video from your belt pack to your ultracool retinal scanning shades (or whatever).
I just want to know who thought up the idea of a UN*X based PDA with a hardware keyboard WITHOUT a pipe character. Gotta use the virtual keyboard for that.
Admittedly, nobody SHOULD need to use the command line on a PDA, but if it can't sync with popular Windows apps, then Linux users must be your target market. If Linux is the selling feature of your product, don't piss those Linux users off!
>...there is nothing to stop a profiler from being built into a C/C++ compiler.
While profile-driven optimizing compiler are interesting, I think you're missing the point here. With a profiling JIT, the information is gathered and used at runtime, not compile time. That means that you're optimizing for THIS run, not some run that you hoped was representative at development time.
For a bogus benchmark, the two approaches are effectively identical -- each benchmark run presumably runs exactly the same code as the last. The compile-time profiler would win simply because it doesn't add any runtime overhead. In an interactive application, say GUI or a game, you can't really predict what functionality any particular user will stress.
Of course, for added fun, the two approaches don't have to be mutually exclusive. There's no reason you can't find and improve many of your code's hot spots at development time, and then let the JIT do its thing at runtime.
So, we end up with MORE water than we started with. The other point to consider is that the conversion process is happening on the demand. You don't convert the entire tank of NaBH4 into H2 instantly, that would defeat then entire idea of "storing" the hydrogen.
Actually, this is the kind of thing that set Goedel off in the first place. His work proved that any such system must contain some basic axioms that you can't prove within the system.
That doesn't make such a description language useless, just funamentally incomplete.
>The only problem with the unit is that it uses WinCE and an embedded processor; this basically means that there is zero application support.
That might seem like a problem to you, but this device is clearly intended for vertical markets. Do you think that a technician using one of these to access online blueprints and doc is going to care if it runs the latest version of [whatever]? How about the delivery guy who uses it to access maps and scan barcodes for package tracking? Setups like this usually run a single app, a small suite at most, and nothing else. The guy delivering packages shouldn't be playing Quake at work anyway.
Counting the number of people who would actually consider using one of these and an everyday machine would probably give you a fairly accurate estimate of the slashdot's population.
Oh boo hoo. Welcome to the world of embedded software development.
First off, if you want to make your code run on a target, you'd better test it on that target. Testing your code in an emulator is sort of like developing web pages for IE4 and just expecting them to work right in IE3, IE5.x, Netscape 4.5-6.0, Mozilla, Opera, Lynx, etc.
The more important lesson, however, is that embedded development tools suck. All of them. As a massively cross-platform developer I've found that Microsoft tools are among the best out there (don't confuse "best" with "good"). Pure GNU environments are adequate, and most of the others range from bizarre to frustrating to unusable.
The MS tools give you GUI and CLI tools and a remote debugger that ACTUALLY WORKS. Yes, you'll need to run NT/2K...get over it.
Pure GNU toolsets give you your familiar friends (gcc/as/ld/etc) in cross-compile form. If you're really lucky there may even be a GDB stub for the target.
More often than not, however, you get a grab bag of crap. One or the more common environments seems to be GNU+hacks on...wait for it...windows! Yes, all your favorite tools in bogus, buggy cygwin form! Just to make sure you don't quietly sneak off to Linux, some important part of the build/test process is encapsulated in a custom windows-only tool, usually an object linker/translator or the downloader. Oh, and no debugger for you. From there, it gets worse. The scale slides all the way down the the Metroworks Palm tools (no CLI, no assembler, and no hope).
As for your complaint about the learning curve on MFC...what do you expect? Win32/MFC is complicated, but so are X/Motif, GTK, EPOC32/Eikon, PalmOS etc. Come to think of it C/C++, perl, vi, emacs, system administration, etc. all take a while to learn too. If it was easy, you wouldn't get paid big bucks to do it.
Perhaps you should look at Java as solution. Lots of smart people are out there busting their butts trying to make Java a viable handheld/embedded dev environment. The development tools are nearly universal and the language/APIs are (mostly) common across platforms. Write-once-run-anywhere is a pipedream, but the stuff out there is a start.
>...the embedded market at some stage over the next few years. I fear for Intels future, in this regard.
Clearly you've forgotten about Intel's XScale architecture (the successor to the StrongARM). The ARM processor currently holds a HUGE segement of the embedded market, and Intel is promising the same low-power high functionality technology at speeds up to 1GHz in the near future. If anything, their presence in the embedded market is growing.
An added bonus of the whole beanstalk idea is that as the structure passes through the earth magnetosphere you'll generate one hell of an induction current. Anyone for wads of clean energy? Of course, you'd probably need most of it to push vehicles up the 36,000 km.
Slashdot Mirror
What's more, "Y2K38" doesn't accurately describe the problem.
I suggest "Y32b" or "Y4B" as more appropriate descriptors.
You'll thank me in 28 years or so when Peter de Jager Jr. makes it a household term.
> 1) You can make your own java compiler.
> 2) You can make your own JVM.
> 3) You can make your own libraries.
> 4) Your java code can be open source.
All these things are true, but the one thing you can't do freely is call any of these things "Java(tm)". That requires having your product pass compliance testing and be certified *by Sun*. The compliance kits are not free (in either sense) and the certification process has a price tag attached as well.
This may not seem like a big deal to the individual user or developer, but when dealing with the corporate world you're nobody unless you have that squiggly coffee-cup logo and the "(tm)". The end result is that if you want to play the Java game, you have to play (and pay) by Sun's rules.
> another Sci Fi series we get to see canceled prematurely
Not necessarily. It could turn out to be craptacular. That pretty much ensures that it'll run for years, cranking out episode after episode, each lamer than the last. Then comes an eternity of syndicated reruns. Maybe even spin-offs!
The truly sad thing is that most of us would keep watching it anyway.
> why don't you guys just buy a few HDs?
Great idea. All they'd need then is some sort of terabyte backup system. Do you recommend CDs, DVDs or tape?
This keeps coming up again and again. No matter how cheap HDs get, they just don't have the durability, portability, or lifetime of "real" offline storage. Sadly, backup technology just isn't keeping up with HD capacities. When >1GB drives first came out, you could get 20GB tapes. Now that we've got 100GB drives, the world needs a TB archive media.
> why don't you try it yourself?
The cause may be good, but not good enough to justify owning a Celine Dion album.
> What is the benefit when the applicable distance is so short?
The first thing that comes to mind is wireless heads-up displays for wearables. Some bogus math:
1024x768 * 32bit * 80Hz = ~2Gb/s
Throw in some compression and other cleverness, and you should have no trouble fitting it in the 500Mb/s they mention. Enjoy streaming digital video from your belt pack to your ultracool retinal scanning shades (or whatever).
> Dog vs. Vampire
Hmmm... things not to say around Buffy fans.
I just want to know who thought up the idea of a UN*X based PDA with a hardware keyboard WITHOUT a pipe character. Gotta use the virtual keyboard for that.
Admittedly, nobody SHOULD need to use the command line on a PDA, but if it can't sync with popular Windows apps, then Linux users must be your target market. If Linux is the selling feature of your product, don't piss those Linux users off!
> ...there is nothing to stop a profiler from being built into a C/C++ compiler.
While profile-driven optimizing compiler are interesting, I think you're missing the point here. With a profiling JIT, the information is gathered and used at runtime, not compile time. That means that you're optimizing for THIS run, not some run that you hoped was representative at development time.
For a bogus benchmark, the two approaches are effectively identical -- each benchmark run presumably runs exactly the same code as the last. The compile-time profiler would win simply because it doesn't add any runtime overhead. In an interactive application, say GUI or a game, you can't really predict what functionality any particular user will stress.
Of course, for added fun, the two approaches don't have to be mutually exclusive. There's no reason you can't find and improve many of your code's hot spots at development time, and then let the JIT do its thing at runtime.
>So does this mean you need a huge water tank?
Um, just follow the reaction:
NaBH4 + 2 H2O ----> 4 H2 + NaBO2
Now, burn the H2:
4 H2 + 2 O2 ----> 4 H2O
So, we end up with MORE water than we started with. The other point to consider is that the conversion process is happening on the demand. You don't convert the entire tank of NaBH4 into H2 instantly, that would defeat then entire idea of "storing" the hydrogen.
> ...wait until the player showed up there, blowing him away upon entry into the game.
So that's where all those camping bastards came from!
>Life is just so much easier now that I've got The Mark.
And remember, only the first few hundred early adopters will have any chance at getting the "special" UID tattooed on their forehead, so sign up now!
"They only have six plots, but they swap them around a bit."
- George Orwell, 1984
Actually, this is the kind of thing that set Goedel off in the first place. His work proved that any such system must contain some basic axioms that you can't prove within the system.
That doesn't make such a description language useless, just funamentally incomplete.
> And where do you think he's gonna get a lawyer from?
Well, I hear the guy downstairs has a pretty good reputation.
>The only problem with the unit is that it uses WinCE and an embedded processor; this basically means that there is zero application support.
That might seem like a problem to you, but this device is clearly intended for vertical markets. Do you think that a technician using one of these to access online blueprints and doc is going to care if it runs the latest version of [whatever]? How about the delivery guy who uses it to access maps and scan barcodes for package tracking? Setups like this usually run a single app, a small suite at most, and nothing else. The guy delivering packages shouldn't be playing Quake at work anyway.
Counting the number of people who would actually consider using one of these and an everyday machine would probably give you a fairly accurate estimate of the slashdot's population.
Oh boo hoo. Welcome to the world of embedded software development.
First off, if you want to make your code run on a target, you'd better test it on that target. Testing your code in an emulator is sort of like developing web pages for IE4 and just expecting them to work right in IE3, IE5.x, Netscape 4.5-6.0, Mozilla, Opera, Lynx, etc.
The more important lesson, however, is that embedded development tools suck. All of them. As a massively cross-platform developer I've found that Microsoft tools are among the best out there (don't confuse "best" with "good"). Pure GNU environments are adequate, and most of the others range from bizarre to frustrating to unusable.
The MS tools give you GUI and CLI tools and a remote debugger that ACTUALLY WORKS. Yes, you'll need to run NT/2K...get over it.
Pure GNU toolsets give you your familiar friends (gcc/as/ld/etc) in cross-compile form. If you're really lucky there may even be a GDB stub for the target.
More often than not, however, you get a grab bag of crap. One or the more common environments seems to be GNU+hacks on...wait for it...windows! Yes, all your favorite tools in bogus, buggy cygwin form! Just to make sure you don't quietly sneak off to Linux, some important part of the build/test process is encapsulated in a custom windows-only tool, usually an object linker/translator or the downloader. Oh, and no debugger for you. From there, it gets worse. The scale slides all the way down the the Metroworks Palm tools (no CLI, no assembler, and no hope).
As for your complaint about the learning curve on MFC...what do you expect? Win32/MFC is complicated, but so are X/Motif, GTK, EPOC32/Eikon, PalmOS etc. Come to think of it C/C++, perl, vi, emacs, system administration, etc. all take a while to learn too. If it was easy, you wouldn't get paid big bucks to do it.
Perhaps you should look at Java as solution. Lots of smart people are out there busting their butts trying to make Java a viable handheld/embedded dev environment. The development tools are nearly universal and the language/APIs are (mostly) common across platforms. Write-once-run-anywhere is a pipedream, but the stuff out there is a start.
>I'd just be exceptionally concerned about accidently wiping out too much of the greenhouse. Without it, we'd be Mars.
Oh come on. How long do you really think it would take the human race to deliberately pollute the atmosphere?
The company: Nexia Biotechnology
The product: BioSteel
>...the embedded market at some stage over the next few years. I fear for Intels future, in this regard.
Clearly you've forgotten about Intel's XScale architecture (the successor to the StrongARM). The ARM processor currently holds a HUGE segement of the embedded market, and Intel is promising the same low-power high functionality technology at speeds up to 1GHz in the near future. If anything, their presence in the embedded market is growing.
First Patent! Woohoo!
Finally! A quality use for those Iridium satellites...
> next they'll have us sign our validation key with some biometric information
Great. Just what we need.
Windows pirating techniques timeline:
Win3.X - floppies
Win95 - borrowed CD
Win2K - CD-R, borrowed CD key
Win2010 - DVD-R, recorded voiceprint
Win2015 - xDVD-RW, fake fingerprints
Win2025 - MiniOpticalDisc, duplicated retinal pattern
Win2040 - MicroOpticalDisc, stolen tissue sample
Win2055 - biochip, false brainwave scan
An added bonus of the whole beanstalk idea is that as the structure passes through the earth magnetosphere you'll generate one hell of an induction current. Anyone for wads of clean energy? Of course, you'd probably need most of it to push vehicles up the 36,000 km.
Of course, I'm sure this article is a complete coincidence in no way related to this one.