Try again. Besides, it's in common usage, so it's as good as part of the language.
Hardware manufacturers are more in the dark ages than many software companies as far as open specs. The hardware interface aren't your crown jewels hardware guys... you can infer a certain amount from it, but not everything. Please, just release specs... we just want to make it work.
You don't understand. Most modern hardware relies heavily on features provided in SOFTWARE. For example, a digital camera can handle video, still shots, zooming, brightness adjusting, etc. because the SOFTWARE knows how to do it. The hardware only provides simple access to a sensor. With this currently being the case, the specs of the hardware tend to be useless. (Unless you want to write all of the replacement functionality yourself.)
This leads into the problem that many hardware manufacturers purchase software components to shorten their development time. Since they don't own this software, they have no right to release its source. (Which they may not even have!) Thus it is more important than ever to provide proper support for binary drivers.
Not at all. This is to prevent people from running old modules against a new kernel version, where symbol names and other internals may have changed, thus resulting in potential crashses, instabilities, etc. As I understand it, you can turn this off by disabling kernel module versioning, but the module itself may refuse to load if it detects the wrong kernel version.
I haven't heard this, but I believe you. It's still an unnecessary restriction. Every other OS is careful to build in a driver interface that is independent of the OS version. Only Linux seems to force things right down to the level of kernel options.
Now if we had to switch drivers between major releases of the Linux kernel (e.g. 2.2 to 2.4), then there'd be no real issue.
Hardware is *far* from useless, even long after it's been "obsoleted". It's only the silly gamerz that require the latest and greatest... most people get by with fairly modest equipment.
It's not a matter of the hardware still being used. Usually you have old copies of software to go with it, too. The real issue is that hardware is a moving target. Chasing around new hardware items to create drivers for, is an exercise in futility. By the time you create the drivers, the hardware has already been replaced with the new model. This means that you HAVE to run old hardware to stay 100% compatible with Linux.
Why bother, when you can get the driver from the manufacturer? The driver can be used for as long as both the hardware is manufactured and Linux doesn't change its driver versions. Once the hardware is no longer supported by the manufacturer and Linux, you can continue running with the older copies of the OS software until an upgrade. That should give you AT LEAST five years before you can't upgrade your core OS.
This is true for graphics cards. Which you *don't* have the source for. On the other hand, you *do* have the source for a wide variety of network cards. All of which does very little good. Manufacturers of these cards revamp the interfaces every few years to meet the new standards in throughput and features. Drats, foiled again!
so as to push hardware manufacturers to make good binary drivers
Question? When did Linux start allowing binary drivers that were not kernel specific? Last time I checked, Linus has jury-rigged the kernel to only allow drivers compiled against a specific version of the kernel. This was in order to force hardware manufacturers to release the source code.
Personally, I think Linux should allow binary drivers. Most hardware is useless in a few years anyway, so what good is having the source? Compare that to the OS, where it can live on for decades.
Considering that Google does not cache images or movies, do I even need to point out how stupid of a post this was? Or were you hoping that the moderators were dumb enough not to notice?
Whoa! Settle down. My only point is that this technology is probably farther away than this press release would make it appear. Many people (including myself, once upon a time) assume that just because it has been announced in the media, it's a reality. This simply isn't the case. The highway of technology is littered with press releases for technology that just plain violated the laws of physics, much less failed to produce a working product.
Now if you want to talk about all the aerospace technology developed in the 50's and 60's that has never seen the light of day, then I'll join you in an upset tirade.
I'm serious here. Mac software products live and die by their rating on VersionTracker. Tucows is similar for Windows software, but it just doesn't have the near 100% of users pull that VersionTracker does.
Oh, and one more hint. Since most people see your software while it's on VersionTracker's front page, release early and release often.
Yes, it's just a simple scaling function. i.e. Back of the envelope calculation. Doesn't mean it's exactly right, but it does give a general idea of how much more data can be read at the same RPM.
It's pretty safe to assume they mean per second. A CD drive has a baseline speed of 150 kb/s. That means that a 48 speed drive has a transfer rate of 7,200 kb/s. Now if we increase the data density to 1 terrabyte, we find that we are now capable of reading 11 gigabytes at the same RPM. Given the greater complexity of this technology, they've probably reduced the RPMs to something more along the lines of an 8 speed drive. This would reduce the data transfer rate, but impose fewer stresses on the media.
...but you can call me when these things are an actual PRODUCT. Many companies have been claiming massive data storage abilities, some in the range of hundreds of terrabytes! Yet not one has provided a realistic product. Problems include:
- Too costly to manufacture at a profit - Holographics are too susceptible to damage from scratches or normal wear - Lasers are difficult to keep calibrated - whole bunch of stuff I'm not aware of
I really would love to see a format that could play hundreds of hours of uncompressed HDTV video. Despite all the press releases, the reality is that it's just not here yet.
Sir, answer me honestly. Have you read the 500 other responses that discussed reuse, photoremediation, and storage? If you did, why are you still posting this?
Exactly. I included the implicit bit in the binary code. (There's an extra bit, check for yourself.) An actual implementation would lack that bit (because it's implicit). Thus the reason for the different numbers.
Ah, I see. You missed my point. I'm not talking about *new* OSes in the 1980's. I'm talking about what business's actually deployed for mission critical work. For one, no one deployed Unix in 1984 for anything other than academics. However, businesses did deploy Unisys MCP (ALGOL), IBM MVS (???), and Symbolics (LISP). No business in their right mind would deploy AmigaOS, MS-DOS, or any of the Unixes.
Check again. I didn't forget it. I just removed the decimal point. (No decimal points in binary.:-)) Of course, there's no implicit bit in a real representation either, but who's counting?
There's an old saying about "the devil is in the details". My post was an extrapolation of what I knew about Alpha particle penetration power. (Hint: It sucks.) Of course, my reasoning was wrong. Similarly, a poster mentioned that Alpha particles have a charge of +1. He was wrong. (Charge is +2.)
The equality function can test for some special condition other than equality: this is not unique to the equality operator.
While this is true, the "equals()" function has (to my knowledge) never been abused in Java.
The equality operator in Java is inconsistent. For simple types it performs a logical comparison and for classes it performs a pointer comparison. So the correct syntax for clarity and conformity in Java should be 3.compareTo(3.00)
Actually, 3.compareTo(3.00) does work in Java 1.5. This is a compiler feature called "autoboxing" which automatically promotes a primitive to an Object and visa-versa.
no they weren't. they were written in assembler. or C.
You want to make a friendly wager on that? (HINT: Read through your sibling posts before answering. And for crying out loud, check some Google results!)
I can be. I try to reserve such behavior for special situations.:-)
The equality operator should be used to invoke built in user defined equality functions as in C++.
It does in Java as well. "boolean result = (3.00 == 3)" will produce "true".
The syntax used by Java is cumbersome and un-intuitive.
Nothing is intuitive. I believe you mean that it's "unnatural". Which is true of programming in general. Thus your complaint really amounts to more of "it's different". Which it is. But we (Java programmers) kind of prefer it to operator overloading.
Operator overloading seemed like a good idea when it was introduced. After all, it made ADTs absolutely transparent. Unfortunately, it's also one of the most abused features in history. Should the addition operator add an object to an array, or should it add the values of one array to another? And who wants to type so much? Just reuse the equality operator to test for some special condition other than equality. Never mind that no one will ever be able to decode what the code is doing.
If you've been a C coder since the 70's, then you know what I'm talking about.:-/
Sometimes I really worry about Slashdot's moderation system. When you get something wrong (but sound like you know), then you get modded up. But when you say something correct, you get modded down as a troll.
Slashdot Mirror
First off, it's jerry-rigged, not jury-rigged.
Try again. Besides, it's in common usage, so it's as good as part of the language.
Hardware manufacturers are more in the dark ages than many software companies as far as open specs. The hardware interface aren't your crown jewels hardware guys... you can infer a certain amount from it, but not everything. Please, just release specs... we just want to make it work.
You don't understand. Most modern hardware relies heavily on features provided in SOFTWARE. For example, a digital camera can handle video, still shots, zooming, brightness adjusting, etc. because the SOFTWARE knows how to do it. The hardware only provides simple access to a sensor. With this currently being the case, the specs of the hardware tend to be useless. (Unless you want to write all of the replacement functionality yourself.)
This leads into the problem that many hardware manufacturers purchase software components to shorten their development time. Since they don't own this software, they have no right to release its source. (Which they may not even have!) Thus it is more important than ever to provide proper support for binary drivers.
Not at all. This is to prevent people from running old modules against a new kernel version, where symbol names and other internals may have changed, thus resulting in potential crashses, instabilities, etc. As I understand it, you can turn this off by disabling kernel module versioning, but the module itself may refuse to load if it detects the wrong kernel version.
I haven't heard this, but I believe you. It's still an unnecessary restriction. Every other OS is careful to build in a driver interface that is independent of the OS version. Only Linux seems to force things right down to the level of kernel options.
Now if we had to switch drivers between major releases of the Linux kernel (e.g. 2.2 to 2.4), then there'd be no real issue.
Hardware is *far* from useless, even long after it's been "obsoleted". It's only the silly gamerz that require the latest and greatest... most people get by with fairly modest equipment.
It's not a matter of the hardware still being used. Usually you have old copies of software to go with it, too. The real issue is that hardware is a moving target. Chasing around new hardware items to create drivers for, is an exercise in futility. By the time you create the drivers, the hardware has already been replaced with the new model. This means that you HAVE to run old hardware to stay 100% compatible with Linux.
Why bother, when you can get the driver from the manufacturer? The driver can be used for as long as both the hardware is manufactured and Linux doesn't change its driver versions. Once the hardware is no longer supported by the manufacturer and Linux, you can continue running with the older copies of the OS software until an upgrade. That should give you AT LEAST five years before you can't upgrade your core OS.
This is true for graphics cards. Which you *don't* have the source for. On the other hand, you *do* have the source for a wide variety of network cards. All of which does very little good. Manufacturers of these cards revamp the interfaces every few years to meet the new standards in throughput and features. Drats, foiled again!
so as to push hardware manufacturers to make good binary drivers
Question? When did Linux start allowing binary drivers that were not kernel specific? Last time I checked, Linus has jury-rigged the kernel to only allow drivers compiled against a specific version of the kernel. This was in order to force hardware manufacturers to release the source code.
Personally, I think Linux should allow binary drivers. Most hardware is useless in a few years anyway, so what good is having the source? Compare that to the OS, where it can live on for decades.
Just in case...
google cache
Considering that Google does not cache images or movies, do I even need to point out how stupid of a post this was? Or were you hoping that the moderators were dumb enough not to notice?
Whoa! Settle down. My only point is that this technology is probably farther away than this press release would make it appear. Many people (including myself, once upon a time) assume that just because it has been announced in the media, it's a reality. This simply isn't the case. The highway of technology is littered with press releases for technology that just plain violated the laws of physics, much less failed to produce a working product.
Now if you want to talk about all the aerospace technology developed in the 50's and 60's that has never seen the light of day, then I'll join you in an upset tirade.
There's only one thing you have to know for Macintosh software:
http://www.versiontracker.com
I'm serious here. Mac software products live and die by their rating on VersionTracker. Tucows is similar for Windows software, but it just doesn't have the near 100% of users pull that VersionTracker does.
Oh, and one more hint. Since most people see your software while it's on VersionTracker's front page, release early and release often.
I'm kind of partial to "the Empire State Building on it's side" measurement. Trying to imagine that is quite a feat!
It's pretty safe to assume they mean per second. A CD drive has a baseline speed of 150 kb/s. That means that a 48 speed drive has a transfer rate of 7,200 kb/s. Now if we increase the data density to 1 terrabyte, we find that we are now capable of reading 11 gigabytes at the same RPM. Given the greater complexity of this technology, they've probably reduced the RPMs to something more along the lines of an 8 speed drive. This would reduce the data transfer rate, but impose fewer stresses on the media.
No, its one gigabyte per library of congress
;-)
How... modern. In MY day we would have said "1 gigabyte per olympic size swimming pool". And we LIKED it that way!
Bah, kids these days.
...but you can call me when these things are an actual PRODUCT. Many companies have been claiming massive data storage abilities, some in the range of hundreds of terrabytes! Yet not one has provided a realistic product. Problems include:
- Too costly to manufacture at a profit
- Holographics are too susceptible to damage from scratches or normal wear
- Lasers are difficult to keep calibrated
- whole bunch of stuff I'm not aware of
I really would love to see a format that could play hundreds of hours of uncompressed HDTV video. Despite all the press releases, the reality is that it's just not here yet.
Sir, answer me honestly. Have you read the 500 other responses that discussed reuse, photoremediation, and storage? If you did, why are you still posting this?
Pssst! I think you mean Strontium-90, not 75. Sr-90 acts a lot like Calcium and thus gets deposited in people's bones.
Exactly. I included the implicit bit in the binary code. (There's an extra bit, check for yourself.) An actual implementation would lack that bit (because it's implicit). Thus the reason for the different numbers.
Ah, I see. You missed my point. I'm not talking about *new* OSes in the 1980's. I'm talking about what business's actually deployed for mission critical work. For one, no one deployed Unix in 1984 for anything other than academics. However, businesses did deploy Unisys MCP (ALGOL), IBM MVS (???), and Symbolics (LISP). No business in their right mind would deploy AmigaOS, MS-DOS, or any of the Unixes.
Check again. I didn't forget it. I just removed the decimal point. (No decimal points in binary. :-)) Of course, there's no implicit bit in a real representation either, but who's counting?
There's an old saying about "the devil is in the details". My post was an extrapolation of what I knew about Alpha particle penetration power. (Hint: It sucks.) Of course, my reasoning was wrong. Similarly, a poster mentioned that Alpha particles have a charge of +1. He was wrong. (Charge is +2.)
The equality function can test for some special condition other than equality: this is not unique to the equality operator.
While this is true, the "equals()" function has (to my knowledge) never been abused in Java.
The equality operator in Java is inconsistent. For simple types it performs a logical comparison and for classes it performs a pointer comparison. So the correct syntax for clarity and conformity in Java should be 3.compareTo(3.00)
Actually, 3.compareTo(3.00) does work in Java 1.5. This is a compiler feature called "autoboxing" which automatically promotes a primitive to an Object and visa-versa.
no they weren't. they were written in assembler. or C.
You want to make a friendly wager on that? (HINT: Read through your sibling posts before answering. And for crying out loud, check some Google results!)
You're quite welcome. ;-)
You are truly a condescending bastard.
:-)
:-/
I can be. I try to reserve such behavior for special situations.
The equality operator should be used to invoke built in user defined equality functions as in C++.
It does in Java as well. "boolean result = (3.00 == 3)" will produce "true".
The syntax used by Java is cumbersome and un-intuitive.
Nothing is intuitive. I believe you mean that it's "unnatural". Which is true of programming in general. Thus your complaint really amounts to more of "it's different". Which it is. But we (Java programmers) kind of prefer it to operator overloading.
Operator overloading seemed like a good idea when it was introduced. After all, it made ADTs absolutely transparent. Unfortunately, it's also one of the most abused features in history. Should the addition operator add an object to an array, or should it add the values of one array to another? And who wants to type so much? Just reuse the equality operator to test for some special condition other than equality. Never mind that no one will ever be able to decode what the code is doing.
If you've been a C coder since the 70's, then you know what I'm talking about.
Sometimes I really worry about Slashdot's moderation system. When you get something wrong (but sound like you know), then you get modded up. But when you say something correct, you get modded down as a troll.
When was "the end of eternity" lost?
:-)
It's been out of print for many, many years. It's only gone back into print recently.
BTW, remind me never to venture a guess about radiation on Slashdot. No one (myself especially) ever seems to get it quite right.
What the fuck are you talking about?
Tsk, tsk, tsk. As the old saying goes, "Profanity is the crutch of a small mind."
3 and 3.00 are not identical at the binary level
Which you claim to have understood.
from a logical stand point they are the same.
Which was fairly obviously not the original poster's point.
The equality operator works as expected in this case.
Which was not something the original poster mentioned.
So why should the equality operator behave differently for other types ?
Because it behaves differently for EVERY type. You have to tell the compiler how to compare them.
If I'm comparing objects I am most likely interested in a logical comparison and not in a comparison of their respective addresses.
Which is why Java has the "equals()" method on objects. Congratulations, you've taken about two hours of time to come to this simplistic conclusion.