is a harddrive with two separate sets of heads on two separate arms -- one for writing and one for reading. This would be very handy for real-time, high-speed, high-volume data collection systems. It'd be nice to not have to reposition the write heads when you're doing random-access reads from the same drive. Nicer still would be two separate SCSI interfaces to the separate head sets.
05-763 RESEARCH IN MOTION, LTD. V. NTP, INC.
The motion of Intel Corporation for leave to file a brief as
amicus curiae is granted. The motion of Canadian Chamber of
Commerce, et al. for leave to file a brief as amici curiae is
granted. The motion of Government of Canada for leave to file
a brief as amicus curiae is granted. The petition for a writ of
certiorari is denied.
I'm seeing a lot more multi-language solutions these days. Extending Python or Perl with C-language extensions. You do the difficult stuff with the higher-level language, and the performance stuff in C. Much easier to do this with Python or Perl than with Java (haven't tried GCJ yet, though).
This thread is getting old now, but the same arguments apply -- when Java was a relatively new language and programming environment, it couldn't have been considered as "mature". The Java wonks and Java hype people worked on that and the language eventually matured. In the very early days of Java, the argument went, "You just wait. Java will be great."
Why wouldn't the same maturation process apply to ROR, TurboGears, etc.?
Here we have the turnabout of another strawman argument.
The real solution is to get a better operating system that allows resource sharing and cheap process creation. Plan 9 is a step in the right direction.
Besides, all the threading models I'm aware of make it difficult to share resources between unrelated threads (or processes). At least SysV IPC, warts and all, allows for sharing between completely unrelated process threads.
Remember folks, threads were invented as a workaround to deal with operating systems that exact heavy penalties for process creation. When you use threads, you're continuing the use of a workaround.
ROR is nice but let's get real - ruby isn't as fast...
Please. For years the Java wonks have been calling performance a strawman argument, usually followed with "get a faster machine".
Now they're using exactly the same performance argument to argue against what is now one of the premier up-and-coming programming environments? Now the table turns; if ROR or my fave the Python-based TurboGears is too slow -- well then, get a faster machine. That argument worked with Java; now it works with Java's replacements.
From TFA: Before pulling away from your crucial Mono project work to write a flame, please hand a normal 25-year-old your Linux box and show them how to connect the system to their bluetooth camera and then smack yourself.
My response: Who cares what the non-techie, point-and-drool end-user wants or needs? Let the commercial people worry about that stuff.
Getting back to the original premise of the story, can you even do OS-level shared memory (SysV or POSIX) with Java? OS-level semaphores? Any meaningful kind of IPC? OS-level anything? I mean without godawful JNI nonsense.
Depends on which GPS module my software is interfacing to. The UTC/GPS offset can be obtained off many of them, but on some older models it's either not available or just plain wrong -- requiring a lot of ugly hacks to get the correct UTC time.
Most GPS modules (as opposed to timing receivers, and who has room in their payloads for a whole 1U sized receiver?) do not provide NTP services; all you get is raw GPS data messages coming in over a serial port. You have to do all the time conversions youself.
This proposal will make my life a living hell. Unless, the leap seconds were added on a strict schedule that was known well in advance. And even with that, I'll still have to change a butt-load of code to accomidate it.
Um, a PIC10 maxes out at 512 bytes of program memory, 23 bytes of RAM, and 2 (count 'em) stack levels. I doubt anyone will be writing a JVM for the thing. Nonetheless, this is an example of a processor that is in widespread use.
Sure, it's great and all, but it'll never change the way the web works. Improve it, yes. Change it? No. You can build as large js-applications as you wish (and yes, spend exponentially as much time debugging them) - you will never escape the fact that you're just building hacks around a stateless technology from pre 90's.
Yeah, well. I don't like Java (specifically, I don't like JVMs), but that doesn't mean that it's (they're) going to go away.
Ajax, like Java, is here to stay. Better get used to it.
Specs are a nice thing in theory, but I have to agree with Linus' point.
If there is to be a new "thing" (ie software component, hardware componenet, interface, or whatever), then we can do one of two things:
1) one can sit down, study the problem a great deal, try to account for all edge- and corner- conditions, and attempt to write a spec which will deal with all these things.
or
2) one could start prototyping the "thing" immediately, ignore unecessary corner- and edge- conditions, bend semantic rules, etc., and get it working, and get it out the door into the {whatever-}space long before the other folks have even completed the spec. Since this would be the first "thing" that people will see, it becomes the de-facto standard (or at least the de-facto strawman) that everyone else will want to interoperate with.
This is the reality. Software moves quickly. In case number 2) the strawman will be iteratively torn apart and rebuilt until a "real" de-facto "spec" emerges. And this will be the "thing" that every one will use.
... when SW people who are are supposedly coding applications that interface directly to hardware (eg samplers, data acquistion modules, GPS modules, etc) know so little about what's going on at the operating system level. More alarming is that they don't seem to care much.
Why Students Are Leaving Engineering
on
Palm's Mistakes
·
· Score: 1
Slashdot asks the (mostly) rhetorical question "Why Are Students Leaving Engineering?", and then answers it with "A hard fall for a company that really did innovate."
It's shit like this, and not Engineering curricula, that are driving students away from Engineering and Technology. What's the point of going through all the pain and effort of getting an Electrical or Computer Engineering degree when even when you and your company do the right thing and innovate, produce, and do good engineering, it all comes to naught.
You're left to the whims of the non-technical market and the board-room dealings of non-technical executives. Engineers are just pawns in thier games. What's the effing point? Engineering isn't engineering anymore. It's business, and anyone in Engineering school better understand that.
The "intimate knowledge" should be written as explicitly a possible, and common workarounds can be put in a cookbook format.
Good idea, except that in most organizations the documentation would be out-of-date as soon as it was completed. We'd spend more and more time making sure that the documentation was up-to-date and less and less time getting work done.
No one will argue against the idea of keeping good documentation, but the reality of the situation is that, often, it's a Sisyphean task.
In practice no one writes code that is like those exercises. Except for people whose code you'll end up maintaining
If they do, then you need to get rid of it and rewrite it....
Uh-huh. Try explaining the added expense of rewriting vs. maintaining. If if you don't have the right "colors" of money in your budget, then you can completely forget rewriting.
intentionally obfuscated "I'm going to do a lot of strange things; prove you can understand this" kind of thing.
You've obviously never worked with people who write code only with their own job security in mind. "If I write it, then I'll have to maintain it forever. Job security!"
Slashdot Mirror
Oh....,
I was sure it was going to be something like:
Windows Vista 3.1
Windows Vista 95
Windows Vista 98
Windows Vista NT
Windows Vista CE
Windows Vista 2000
Windows Vista 2003
Windows Vista XP
is a harddrive with two separate sets of heads on two separate arms -- one for writing and one for reading. This would be very handy for real-time, high-speed, high-volume data collection systems. It'd be nice to not have to reposition the write heads when you're doing random-access reads from the same drive. Nicer still would be two separate SCSI interfaces to the separate head sets.
I don't know about love, but I do know this:
In a market economy, the only real measure of success is wealth.
Shame that we live in a market economy.
05-763 RESEARCH IN MOTION, LTD. V. NTP, INC. The motion of Intel Corporation for leave to file a brief as amicus curiae is granted. The motion of Canadian Chamber of Commerce, et al. for leave to file a brief as amici curiae is granted. The motion of Government of Canada for leave to file a brief as amicus curiae is granted. The petition for a writ of certiorari is denied.
It is this, and not outsourcing, that will bring the United States to its knees.
I'm seeing a lot more multi-language solutions these days. Extending Python or Perl with C-language extensions. You do the difficult stuff with the higher-level language, and the performance stuff in C. Much easier to do this with Python or Perl than with Java (haven't tried GCJ yet, though).
Why wouldn't the same maturation process apply to ROR, TurboGears, etc.?
Here we have the turnabout of another strawman argument.
Besides, all the threading models I'm aware of make it difficult to share resources between unrelated threads (or processes). At least SysV IPC, warts and all, allows for sharing between completely unrelated process threads.
Remember folks, threads were invented as a workaround to deal with operating systems that exact heavy penalties for process creation. When you use threads, you're continuing the use of a workaround.
Please. For years the Java wonks have been calling performance a strawman argument, usually followed with "get a faster machine".
Now they're using exactly the same performance argument to argue against what is now one of the premier up-and-coming programming environments? Now the table turns; if ROR or my fave the Python-based TurboGears is too slow -- well then, get a faster machine. That argument worked with Java; now it works with Java's replacements.
My response: Who cares what the non-techie, point-and-drool end-user wants or needs? Let the commercial people worry about that stuff.
Like Java, right?
Getting back to the original premise of the story, can you even do OS-level shared memory (SysV or POSIX) with Java? OS-level semaphores? Any meaningful kind of IPC? OS-level anything? I mean without godawful JNI nonsense.
Depends on which GPS module my software is interfacing to. The UTC/GPS offset can be obtained off many of them, but on some older models it's either not available or just plain wrong -- requiring a lot of ugly hacks to get the correct UTC time.
Most GPS modules (as opposed to timing receivers, and who has room in their payloads for a whole 1U sized receiver?) do not provide NTP services; all you get is raw GPS data messages coming in over a serial port. You have to do all the time conversions youself.
This proposal will make my life a living hell. Unless, the leap seconds were added on a strict schedule that was known well in advance. And even with that, I'll still have to change a butt-load of code to accomidate it.
Um, a PIC10 maxes out at 512 bytes of program memory, 23 bytes of RAM, and 2 (count 'em) stack levels. I doubt anyone will be writing a JVM for the thing. Nonetheless, this is an example of a processor that is in widespread use.
Okie dokie, can you help me find a JVM for a PIC 10F200 microcontroller? http://www.microchip.com/stellent/idcplg?IdcServic e=SS_GET_PAGE&nodeId=2061¶m=en505736
Yeah, well. I don't like Java (specifically, I don't like JVMs), but that doesn't mean that it's (they're) going to go away.
Ajax, like Java, is here to stay. Better get used to it.
Specs are a nice thing in theory, but I have to agree with Linus' point.
If there is to be a new "thing" (ie software component, hardware componenet, interface, or whatever), then we can do one of two things:
1) one can sit down, study the problem a great deal, try to account for all edge- and corner- conditions, and attempt to write a spec which will deal with all these things.
or
2) one could start prototyping the "thing" immediately, ignore unecessary corner- and edge- conditions, bend semantic rules, etc., and get it working, and get it out the door into the {whatever-}space long before the other folks have even completed the spec. Since this would be the first "thing" that people will see, it becomes the de-facto standard (or at least the de-facto strawman) that everyone else will want to interoperate with.
This is the reality. Software moves quickly. In case number 2) the strawman will be iteratively torn apart and rebuilt until a "real" de-facto "spec" emerges. And this will be the "thing" that every one will use.
... when SW people who are are supposedly coding applications that interface directly to hardware (eg samplers, data acquistion modules, GPS modules, etc) know so little about what's going on at the operating system level. More alarming is that they don't seem to care much.
It's shit like this, and not Engineering curricula, that are driving students away from Engineering and Technology. What's the point of going through all the pain and effort of getting an Electrical or Computer Engineering degree when even when you and your company do the right thing and innovate, produce, and do good engineering, it all comes to naught.
You're left to the whims of the non-technical market and the board-room dealings of non-technical executives. Engineers are just pawns in thier games. What's the effing point? Engineering isn't engineering anymore. It's business , and anyone in Engineering school better understand that.
I wish someone had explained that to me long ago.
The "intimate knowledge" should be written as explicitly a possible, and common workarounds can be put in a cookbook format.
Good idea, except that in most organizations the documentation would be out-of-date as soon as it was completed. We'd spend more and more time making sure that the documentation was up-to-date and less and less time getting work done.
No one will argue against the idea of keeping good documentation, but the reality of the situation is that, often, it's a Sisyphean task.
As if commercial software doesn't suffer from the same problems?
Imagine a Beowulf clusters of these things!!!
Except for people whose code you'll end up maintaining
If they do, then you need to get rid of it and rewrite it ....
Uh-huh. Try explaining the added expense of rewriting vs. maintaining. If if you don't have the right "colors" of money in your budget, then you can completely forget rewriting.
intentionally obfuscated "I'm going to do a lot of strange things; prove you can understand this" kind of thing.
You've obviously never worked with people who write code only with their own job security in mind. "If I write it, then I'll have to maintain it forever. Job security!"
...is seamless integration with iTunes.
Otherwise, no sale.