Have you ever written a line of code? Do you have any clue how difficult it is to get random disperse groups of programmers to document and communicate well enough about kernel changes so that drivers can be updated without causing problems?
I have encountered some of those problems personally while working on Inkscape, so your suppositions sound funny to me. Those are difficult problems but that doesn't mean you shouldn't try to solve them. Many have.
You think that just because they open source it, someone will make it better?
Yes! I thought it was the very point of free software. I have also seen it happen (e.g. the tc1100-wmi driver).
Do you think you know more about the hardware than the company making the hardware, so you could write a better driver?
There is more to programming drivers than knowing the hardware. Example: the interface to a Wacom tablet is fairly simple, yet a good driver is hard to implement, because it has to do a lot of bookkeeping to know the current state of the device, as well as implement calibration, pressure curve adjustment, etc. At some point the kernel can get a common architecture for input calibration. If you can adapt the driver to it, it's an improvement, because the abstraction provided by the driver is more useful. Knowing the hardware is just the beginning.
You don't get more companies supporting your OS with so little market share that its statistically irrelevant by making it hard for them.
It's not terribly harder to write an open source driver instead of a closed source one. If you do it, do it right from the beginning. Sometimes it's even easier than writing a closed source driver, because others will bugfix your code.
By the way, your definition of statistical irrelevance would be really scary for a statistician. (Only 1% of people die after this drug is administered? Who cares, it's statistically insignificant.)
Your argument really seems to be more of a 'its not good unless its open sources' kind of thing, which just makes you a GPL fundamentalist and an idiot with nothing to actually contribute.
I like how you resort to ad hominem to get your point across.
GPL zealots really need to get the hell over this 'its bad if its not GPL' additude if you want to play with the big boys.
Yeah, it sure worked perfectly for the BSD people. (I sense a flamewar.) You need to grasp the idea that free software's goal is not to replace Microsoft or anything like that. It is to transform the way we think about software code: not as a trade secret that should be hoarded and protected, but as a commons that can be collectively improved upon and learned from.
"Oh Microsoft is bad cause they make you follow their rules"
Did I say anything about MS? By the way, who thinks that MS is evil because they have certification programs? I don't write or use Windows drivers, so why should I care about Microsoft's driver policy?
but... "Linux is good because you have to follow their rules".
If their rules were the same, that would be hypocrisy, but they are not. A restaurant owner that doesn't let in black people is different from one who doesn't let in smokers. You could say that the first is bad for the same reason the second is good. Regardless, the Linux rules are reasonable: if we are to help you, we need to know that the problem is at our side, and not in a proprietary driver; we will also not help you to make our lives harder in the future.
Kernel ABI has nothing to do with userland apps! Userland apps do not use the kernel APIs AT ALL. They use the userland kernel API, which is very stable. You can run VERY old programs on Linux with no breakage.
Have you used some recent Linux distribution? Do you know that the last number in the kernel version (e.g. 2.6.27-11) is usually the ABI version? The kernel ABI changes every time the kernel is recompiled. Yet somehow I don't have to recompile all my programs every time I upgrade the kernel. This is because userland programs do not use the kernel ABI. The only thing that has to be recompiled are the drivers.
Stable kernel ABI is useful for exactly one thing: closed source drivers. It allows you to ship a single binary driver for all versions of the kernel. We don't want them, and a stable kernel ABI causes a lot of problems, so there is no reason to have it.
Finally the truth slips out. We don't want stable API's, because we don't want closed source code. Okay. So then say it. We don't want 'the year of the Linux desktop'. Or not enough to compromise ideological purity.
We don't want *closed source drivers*. Not closed source apps. Kernel ABI has NOTHING to do with userland software APIs. I think you are brainfucked by Microsoft which somehow convinced everybody that you have a single API for the whole system, and that API = ABI.
CD-RW will only last for 100 writes. Have you ever seen a failed CD-RW? I didn't. Even if you had a nanotube drive that you completely overwrote every hour, it would last for 2 years. An USB drive with 100k writes would last for 11 years. In real life scenarios drives are rarely written to more than a few times a day, and certainly not in the same places. This can be further reduced with wear leveling filesystems. The only reason we don't use those widely is that it's extremely hard to write a filesystem driver for Windows.
App installation is STILL going to have to: -- become as simple as click on the.tar, no yum/apt-get/ whatever
Which is simpler: 1. Search for a program that does X 2. Find a website of the program Y among lots of noise 3. Check whether it is trusted 4. Click "Download Y" 5. Wait for Y to download 6....after being distracted by something, come back and run the installer 7. Click through some completely unnecessary questions that give the user an illusion of control over the software 8. Run the program or: 1. Open Add/Remove 2. Search for a program that does X 3. Install program Y 4. Run the program
-- be as smart as installing with a click (after permissions have been determined valid and authorized)
How do you imagine this? This gives a false perception of security, because a virus can simulate the click for you and install things you don't want.
-- and the installer will ALSO have to be smart enough to know how to just search for the Internet-available-but-signed-trusted choices of file are
This could take the form of searching e.g. Launchpad PPAs, but again this could be a security risk. It's quite hard to make something easy for you while not making it easy for others to hijack.
I have on occasion probably used yum and apt-get and to a greater extent rpm and tar files. It SHOULD be easier. I am sure it IS easy. But, for me, it does not always work. If I have a need to get Rhyme working, and not all the deps are there, it's a show-stopper to face "repository not found", "dependencies (collide/incompatible...)"
The dependency hell problems are puzzling to me because I have never experienced them. Now I think this boils down to RPM being shit, because I have only used Debian-based distributions. Debian has nice things like pbuilder which make those problems easy to spot and fix.
App install in Linux is not a significant factor holding it back. The only two ones are: 1. Lack of specialty software (for example, a decent chemical structure editor), 2. Microsoft intimidating OEMs.
Backward compatibility is Windows' biggest strength - perhaps its only strength compared to the competition. And Linux will never have it, because it's creators don't want it, or don't understand why it's important, or just don't care.
1. This is just FUD spread by people who want to ship binary drivers for Linux. Application level compatibility is actually quite good. For example you can still run GTK 1.x apps on modern Gnome desktops. 2. Backward compatibility mostly matters for legacy proprietary apps. Since there aren't too many of those for Linux, this issue is not an important factor in Linux adoption. 3. Stable kernel ABI would actually be harmful for Linux, because manufacturers wouldn't be as willing to release open-source drivers. Right now they do mainly because it takes considerable manpower to maintain a closed-source driver.
It just gets the system date you have set... It doesn't compare it to any external sources, it just compares the SSL certificate expiration date with the system date. So it doesn't care whether the date is out of sync with the world, it just assumes it's correct.
Still, it doesn't nag you with "please reboot now or else" screens every 15 minutes, it just lets you continue your work and reboot when you're finished. You can also just kill the notification process if the kernel update won't affect you (e.g. minor exploit in a feature or fixes for drivers you don't use).
As far as efficiency goes, in the old days it was true that a coder with an intimate knowledge of the architecture could usually hand code more efficient assembly. Modern C compilers however can do a LOT of optimization and generally the resulting code is faster than anything that could be coded by hand, or at least AS fast.
1. You still have to know what C code will compile to the most efficient assembly representation. For example, computing a sum of 1 million floats will have different performance when you add to a single variable in a loop, and when you use 16 variables as subtotals and add those in the last step (depending on the number of execution units in the CPU it can be up to 16 times faster). 2. Compilers are usually not clever enough to use conditional moves and other conditional instructions that avoid branching. This is important, since branching overhead is rather large in modern deeply pipelined processors. 3. It's actually quite easy to beat a compiler when you know what you're doing. I'm not an experienced assembly programmer by any measure and I did this a few times. The reason few people use assembly today is that the code is then no longer portable, and it's much easier to introduce bugs.
Apple is not a monopoly player in the OS market using it to obtain a monopoly in the browser market. This is what the antitrust laws are about: not about preventing monopolies, but about preventing the abuse of monopoly position in one market to gain an an unfair advantage in another.
I remember reading about the same proposition in a Scientific American article about 3 years ago (I used to read my national edition and there is a lag). However, they were basing the proposition on the analysis of the thermodynamical properties of black holes. Apparently the maximum entropy of a system is determined by the surface area of a sphere that encloses it. Above this limit the matter collapses into a black hole, which has an entropy proportional to its surface area.
OK, you are criticizing a lot. But what should we do? Run ad campaigns in the TV? Install OpenOffice masqueraded as Microsoft Word and get sued? Put Internet Explorer icons on the desktop? Detect Verizon CDs and run our own substitute application with Verizon logos and get sued as well? At this point the problem is not that the software is not usable, or that people refuse to fix it. It is the users, which don't even know what they want to do.
Or maybe you want to say "If someone is completely uninformed and wants Windows, don't try to inform them"? Sorry, but we are not going to do this - otherwise nothing will change.
Basically you have users thinking in terms of the tools they use and not in terms of the things they want to do. This is because of marketing-based education that someone else mentioned earlier. Getting back at cars, if you have someone saying "I want to get into a Ford, put in the forward gear and press the accelerator until I see a low white building with a big parking lot" instead of "I want to go shopping", you can't do much about mass transit to make it more usable to them - they won't have tickets, move their arms like they wanted to steer in the passenger seat and look surprised when the bus doesn't turn, look in vain for the gearbox and complain there isn't one etc. no matter what the mass transit system looks like, until they realize that getting to a destination is not fundamentally dependent on driving a Ford, and that a tool is not equal to the goal of its use.
The only thing we can do is education - this will be painful, slow and unrewarding, but in the end maybe it will make the world better.
Raw images are the digitized output from the sensor with no processing applied. Processing speed is not the problem because there just isn't any. The bottleneck is the flash write speed. You'd have to wait a few seconds between photos while the camera writes the large raw picture. Better cameras just have some RAM to let you take more photos while they're writing to the card.
I find it incredibly irritating that the default for nearly every distro is to overwrite the existing bootloader rather than attempt to use a more sane solution: add their OS to the existing bootloader when installing on a separate partition.
It would involve writing to an NTFS partition, and modifying Windows' files. In short, not a good idea.
Well, not anymore... The president is still in office, but politically marginalized, and the second guy lost his grip on the Parliament in pre-term elections. It was a very big suddenoutbreakofcommonsense. The current prime minister is much more sensible.
It would be trivial to write a Windows filesystem driver
FS drivers are the least trivial of all, and moreover Windows IFS drivers are incompatible between Windows versions. So you would have to write at least 4 different drivers just to cover the NT family.
Slashdot Mirror
Have you ever written a line of code? Do you have any clue how difficult it is to get random disperse groups of programmers to document and communicate well enough about kernel changes so that drivers can be updated without causing problems?
I have encountered some of those problems personally while working on Inkscape, so your suppositions sound funny to me. Those are difficult problems but that doesn't mean you shouldn't try to solve them. Many have.
You think that just because they open source it, someone will make it better?
Yes! I thought it was the very point of free software. I have also seen it happen (e.g. the tc1100-wmi driver).
Do you think you know more about the hardware than the company making the hardware, so you could write a better driver?
There is more to programming drivers than knowing the hardware. Example: the interface to a Wacom tablet is fairly simple, yet a good driver is hard to implement, because it has to do a lot of bookkeeping to know the current state of the device, as well as implement calibration, pressure curve adjustment, etc. At some point the kernel can get a common architecture for input calibration. If you can adapt the driver to it, it's an improvement, because the abstraction provided by the driver is more useful. Knowing the hardware is just the beginning.
You don't get more companies supporting your OS with so little market share that its statistically irrelevant by making it hard for them.
It's not terribly harder to write an open source driver instead of a closed source one. If you do it, do it right from the beginning. Sometimes it's even easier than writing a closed source driver, because others will bugfix your code.
By the way, your definition of statistical irrelevance would be really scary for a statistician. (Only 1% of people die after this drug is administered? Who cares, it's statistically insignificant.)
Your argument really seems to be more of a 'its not good unless its open sources' kind of thing, which just makes you a GPL fundamentalist and an idiot with nothing to actually contribute.
I like how you resort to ad hominem to get your point across.
GPL zealots really need to get the hell over this 'its bad if its not GPL' additude if you want to play with the big boys.
Yeah, it sure worked perfectly for the BSD people. (I sense a flamewar.) You need to grasp the idea that free software's goal is not to replace Microsoft or anything like that. It is to transform the way we think about software code: not as a trade secret that should be hoarded and protected, but as a commons that can be collectively improved upon and learned from.
"Oh Microsoft is bad cause they make you follow their rules"
Did I say anything about MS? By the way, who thinks that MS is evil because they have certification programs? I don't write or use Windows drivers, so why should I care about Microsoft's driver policy?
but ... "Linux is good because you have to follow their rules".
If their rules were the same, that would be hypocrisy, but they are not. A restaurant owner that doesn't let in black people is different from one who doesn't let in smokers. You could say that the first is bad for the same reason the second is good. Regardless, the Linux rules are reasonable: if we are to help you, we need to know that the problem is at our side, and not in a proprietary driver; we will also not help you to make our lives harder in the future.
Kernel ABI has nothing to do with userland apps! Userland apps do not use the kernel APIs AT ALL. They use the userland kernel API, which is very stable. You can run VERY old programs on Linux with no breakage.
Have you used some recent Linux distribution? Do you know that the last number in the kernel version (e.g. 2.6.27-11) is usually the ABI version? The kernel ABI changes every time the kernel is recompiled. Yet somehow I don't have to recompile all my programs every time I upgrade the kernel. This is because userland programs do not use the kernel ABI. The only thing that has to be recompiled are the drivers.
Stable kernel ABI is useful for exactly one thing: closed source drivers. It allows you to ship a single binary driver for all versions of the kernel. We don't want them, and a stable kernel ABI causes a lot of problems, so there is no reason to have it.
Finally the truth slips out. We don't want stable API's, because we don't want closed source code. Okay. So then say it. We don't want 'the year of the Linux desktop'. Or not enough to compromise ideological purity.
We don't want *closed source drivers*. Not closed source apps. Kernel ABI has NOTHING to do with userland software APIs. I think you are brainfucked by Microsoft which somehow convinced everybody that you have a single API for the whole system, and that API = ABI.
CD-RW will only last for 100 writes. Have you ever seen a failed CD-RW? I didn't. Even if you had a nanotube drive that you completely overwrote every hour, it would last for 2 years. An USB drive with 100k writes would last for 11 years. In real life scenarios drives are rarely written to more than a few times a day, and certainly not in the same places. This can be further reduced with wear leveling filesystems. The only reason we don't use those widely is that it's extremely hard to write a filesystem driver for Windows.
Same thing.
App installation is STILL going to have to: .tar, no yum /apt-get/ whatever
-- become as simple as click on the
Which is simpler: ...after being distracted by something, come back and run the installer
1. Search for a program that does X
2. Find a website of the program Y among lots of noise
3. Check whether it is trusted
4. Click "Download Y"
5. Wait for Y to download
6.
7. Click through some completely unnecessary questions that give the user an illusion of control over the software
8. Run the program
or:
1. Open Add/Remove
2. Search for a program that does X
3. Install program Y
4. Run the program
-- be as smart as installing with a click (after permissions have been determined valid and authorized)
How do you imagine this? This gives a false perception of security, because a virus can simulate the click for you and install things you don't want.
-- and the installer will ALSO have to be smart enough to know how to just search for the Internet-available-but-signed-trusted choices of file are
This could take the form of searching e.g. Launchpad PPAs, but again this could be a security risk. It's quite hard to make something easy for you while not making it easy for others to hijack.
I have on occasion probably used yum and apt-get and to a greater extent rpm and tar files. It SHOULD be easier. I am sure it IS easy. But, for me, it does not always work. If I have a need to get Rhyme working, and not all the deps are there, it's a show-stopper to face "repository not found", "dependencies (collide/incompatible...)"
The dependency hell problems are puzzling to me because I have never experienced them. Now I think this boils down to RPM being shit, because I have only used Debian-based distributions. Debian has nice things like pbuilder which make those problems easy to spot and fix.
App install in Linux is not a significant factor holding it back. The only two ones are: 1. Lack of specialty software (for example, a decent chemical structure editor), 2. Microsoft intimidating OEMs.
Backward compatibility is Windows' biggest strength - perhaps its only strength compared to the competition. And Linux will never have it, because it's creators don't want it, or don't understand why it's important, or just don't care.
1. This is just FUD spread by people who want to ship binary drivers for Linux. Application level compatibility is actually quite good. For example you can still run GTK 1.x apps on modern Gnome desktops.
2. Backward compatibility mostly matters for legacy proprietary apps. Since there aren't too many of those for Linux, this issue is not an important factor in Linux adoption.
3. Stable kernel ABI would actually be harmful for Linux, because manufacturers wouldn't be as willing to release open-source drivers. Right now they do mainly because it takes considerable manpower to maintain a closed-source driver.
It just gets the system date you have set... It doesn't compare it to any external sources, it just compares the SSL certificate expiration date with the system date. So it doesn't care whether the date is out of sync with the world, it just assumes it's correct.
Still, it doesn't nag you with "please reboot now or else" screens every 15 minutes, it just lets you continue your work and reboot when you're finished. You can also just kill the notification process if the kernel update won't affect you (e.g. minor exploit in a feature or fixes for drivers you don't use).
You fail at reading comprehension, from GP:
have VMWare make a nice 32bit, 3GB of ram, dual processor for XP
He'll only allocate 3GB of RAM and 2 cores for use in the XP virtual machine.
Yeah, this phrase was never more appropriate
Not exactly - you need a support library (usually written in C...) which will do things like virtual method lookups and exception handling for you.
As far as efficiency goes, in the old days it was true that a coder with an intimate knowledge of the architecture could usually hand code more efficient assembly. Modern C compilers however can do a LOT of optimization and generally the resulting code is faster than anything that could be coded by hand, or at least AS fast.
1. You still have to know what C code will compile to the most efficient assembly representation. For example, computing a sum of 1 million floats will have different performance when you add to a single variable in a loop, and when you use 16 variables as subtotals and add those in the last step (depending on the number of execution units in the CPU it can be up to 16 times faster).
2. Compilers are usually not clever enough to use conditional moves and other conditional instructions that avoid branching. This is important, since branching overhead is rather large in modern deeply pipelined processors.
3. It's actually quite easy to beat a compiler when you know what you're doing. I'm not an experienced assembly programmer by any measure and I did this a few times. The reason few people use assembly today is that the code is then no longer portable, and it's much easier to introduce bugs.
Apple is not a monopoly player in the OS market using it to obtain a monopoly in the browser market. This is what the antitrust laws are about: not about preventing monopolies, but about preventing the abuse of monopoly position in one market to gain an an unfair advantage in another.
Huh? I thought it was the unregulated American financial sector that caused this world-scale shitstorm. Way to shift blame.
I remember reading about the same proposition in a Scientific American article about 3 years ago (I used to read my national edition and there is a lag). However, they were basing the proposition on the analysis of the thermodynamical properties of black holes. Apparently the maximum entropy of a system is determined by the surface area of a sphere that encloses it. Above this limit the matter collapses into a black hole, which has an entropy proportional to its surface area.
http://www.sciam.com/article.cfm?id=information-in-the-hologr-2003-08
OK, you are criticizing a lot. But what should we do? Run ad campaigns in the TV? Install OpenOffice masqueraded as Microsoft Word and get sued? Put Internet Explorer icons on the desktop? Detect Verizon CDs and run our own substitute application with Verizon logos and get sued as well? At this point the problem is not that the software is not usable, or that people refuse to fix it. It is the users, which don't even know what they want to do.
Or maybe you want to say "If someone is completely uninformed and wants Windows, don't try to inform them"? Sorry, but we are not going to do this - otherwise nothing will change.
Basically you have users thinking in terms of the tools they use and not in terms of the things they want to do. This is because of marketing-based education that someone else mentioned earlier. Getting back at cars, if you have someone saying "I want to get into a Ford, put in the forward gear and press the accelerator until I see a low white building with a big parking lot" instead of "I want to go shopping", you can't do much about mass transit to make it more usable to them - they won't have tickets, move their arms like they wanted to steer in the passenger seat and look surprised when the bus doesn't turn, look in vain for the gearbox and complain there isn't one etc. no matter what the mass transit system looks like, until they realize that getting to a destination is not fundamentally dependent on driving a Ford, and that a tool is not equal to the goal of its use.
The only thing we can do is education - this will be painful, slow and unrewarding, but in the end maybe it will make the world better.
Let's focus on the applications and not on reinventing the wheel.
How is porting to another toolkit (which would involve an incredible amount of resources and bring no tangible benefits) not "reinventing the wheel"?
Raw images are the digitized output from the sensor with no processing applied. Processing speed is not the problem because there just isn't any. The bottleneck is the flash write speed. You'd have to wait a few seconds between photos while the camera writes the large raw picture. Better cameras just have some RAM to let you take more photos while they're writing to the card.
an AWESOME improvement to the defragmenter that makes me actually want to use it
That sounds like a better shovel to clean up the dung of your horses when everybody else is driving cars.
I find it incredibly irritating that the default for nearly every distro is to overwrite the existing bootloader rather than attempt to use a more sane solution: add their OS to the existing bootloader when installing on a separate partition.
It would involve writing to an NTFS partition, and modifying Windows' files. In short, not a good idea.
I'm rather surprised that Dell chose Poland rather than, say, Moldova, though.
Many skilled CS graduates?
http://www.theregister.co.uk/2006/07/06/code_jam_europe/
Though I expect there will be mainly manual jobs created, so maybe this isn't very relevant.
Well, not anymore... The president is still in office, but politically marginalized, and the second guy lost his grip on the Parliament in pre-term elections. It was a very big suddenoutbreakofcommonsense. The current prime minister is much more sensible.
It would be trivial to write a Windows filesystem driver
FS drivers are the least trivial of all, and moreover Windows IFS drivers are incompatible between Windows versions. So you would have to write at least 4 different drivers just to cover the NT family.
"For every year y where y = 2008, y is interesting" - this makes sense in the mathematic sense, but in the language sense it doesn't.