The thing is, Linux CAN support sound-cards. Sound-card support has been around since I started using Linux in '97, and it wasn't new then. The problem is that not all cards work in Linux. There is only one reason for this:
Hardware vendors still do not care about Linux.
There are some vendors who care, and their stuff is supported. Creative Labs even open-sourced the SB Live/Audigy driver (they probably aren't the only one, but that's what card I have, so I know that one's available). So Creative cards work great... just load Linux, and there it goes.
Linux on the desktop is not impossible. In terms of functionality, Linux is equal to Windows in some areas, surpasses it in others, and lacks in some. That's to be expected; you could claim that Windows isn't ready for the desktop, look how much more usable Linux is for this or that! But that's not the point; people will use what they have as long as most things work most of the time.
The difference between, say, Windows 95 and OS/2 in 1995 was A) Microsoft's monopoly tactics that shut out OS/2, and B) Nobody supporting OS/2 anyway. So if you can't get hardware drivers for your OS/2 box, but you can for your Windows box, Windows must be better, right? OS/2 must not be ready for the desktop, right? It's the same thing now, with Linux. Linux is as good as Windows for most tasks that home users care about. In some, it's worse, in others, it's better. For installing supported hardware, it's easier in Linux than Windows (in my experience, working in a computer service dept, and using Linux at home). For partially supported hardware in Linux, it's usually easier in Windows. For unsupported hardware in Linux, it's obviously easier in Windows. But that's not Linux's fault.
How about, Christ generally didn't use violent means; in the end he gave up his life to make his point? At the time he was arrested he had enough followers to raise an army. So it's truly different from the Doom story.
Doom just caters to our tendencies to enjoy violence, and provides an arena for us to wallow in. The fact that there are "demons" is irrelevant; just replace "army of demons suddenly attacking" with "army of aliens suddenly attacking" or "army of terrorists suddenly attacking" and you have the same game with different sprites.
I asked the same question to a university prof I had who consulted for NASA and he claimed that many people at NASA actually do all their work in imperial measurements, and they actually tried to make the ISS an all-imperial system. Still I think it's rather stupid that they can't use the standard measurement system.
I'd say you can generally expect that people don't have an ancient version of a browser, but the proper thing to do is find out what your site-visitors are using so that you can code the site appropriately. If your target audience has a significant portion running Netscape 4, you're probably stuck supporting it.
Asking people to upgrade their browser IS a problem, for many people. For instance, at work my employer only lets me use the version of IE that's installed on my computer. I am certainly not allowed to upgrade it, nor am I even allowed to install mozilla or some other browser. A good website designer can't just look at what features are supported on SOME version of a popular browser, he/she has to look at what the expected clients will be using. So if a significant percent of your expected visitors are likely to be using IE 5, you can't rely on IE-6 features and expect them to be happy.
I have developed code of significance without unit testing, and I can assure you that the quality of that code was far inferior to the quality of the code developed with more attention paid to unit tests. In the projects I've worked on, sometimes the manager has made the decision to skip unit tests in order to concentrate on features. It's true that those features can be worked on at a faster rate, and seemingly completed sooner. But inevitably, the number of bugs found in QA, and the amount of time spent revising the code eats up any savings. Even if we break even, in terms of time (which, in my experience, would be a generous assumption), then the non-unit-tested project finishes at the same time but has no suite of tests to carry forward to the next version.
Furthermore, the benefits of testing are not just related to finding bugs sooner in the initial version. The tests can help influence the design of the code. I've written code where I ended up refactoring it completely while writing the tests, because the initial version, while it worked, didn't wasn't easily testable or had too many redundancies in the code. The quality of the run-time product was the same, but the source code improved dramatically just because I wrote tests for it.
Also, having the unit tests is a good way to ensure that bugs aren't introduced later. In short, the benefits are so high that, while I can imagine (and have actually done it) working on a project with no tests, it's not a task that I would welcome. It's similar to asking me to work on a task with no debugger, or no source-code control system. Yes, it's possible, and heck, the Linux kernel was written without either of these things, but realistically these are vital tools for software development. To me, unit tests are another of those vital tools.
Isn't there an X server that's designed for testing? Or, perhaps you could write a simple application that interacts with your window manager, and your application can ask the window manager to do something, and then verify the result.
But you're in the arena of gui testing, which is hard. Everyone admits that it's hard. But for many applications, you can separate the gui from the parts that do the real work, and then test those parts. In some cases this can even give you a huge benefit in terms of program architecture, making it easier to maintain, upgrade and port.
I think if you're creative you'll find a way to test your application. And if not, you could consider writing a fake X server. It might be worthwhile looking at one that can be easily modified or controlled. Perhaps one of the Java X servers could do the trick, since it's easy to integrate one java program into another.
Where I work, unit tests are a requirement, not a luxury. WIthout fail, the projects with the most unit tests have the fewest bugs, and the projects with the fewest unit tests have the most bugs. I'm not exagerating.
My question to you is, if you have no unit tests, how can you be sure that the code works at all? Manual testing? Do you cover all the code paths with manual testing? It must take forever, or your application is rather trivial.
Supermount is more like automount than autorun. It's like automount for removable media. Baiscally, your removable media is always "mounted" as type supermount, and when you access it, supermount accesses the actual device, so the user can insert/remove media and supermount magically handles it. I'm not sure what happens if the user replaces the media while it's in use, since I've never tried that:)
It's not that people can't handle a different software package. They can, if they have to. But any time spent learning that new tool, or re-writing macros, or working around limitations in that tool is time that could be spent doing real work. All of that has to be factored into the cost of switching. In my job, I am required to work in Java or C++, depending on what project I'm working on. I don't get to whine, I just do what I have to. Each has its strengths and weaknesses, but I am forced to use one or the other depending on the task. But for my office correspondence? It's MS Word. It's there, I use it, I get stuff done. (Though I prefer Word Perfect, myself). Any time not spent messing around with my word processor is time I can spend coding. If my company were to switch to another word processor, they'd have to take into account all the time I, and my other coworkers, would spend messing around with the new program instead of coding. That's the cost of switching.
Anti-Lock brakes, they actually increase breaking distance and if you pump them (like anyone over the age of 26 was trained to do) you are screwed.
Anti-lock breaks increase stopping distance over properly-executed threshold breaking, but I think it's terribly naive to claim that the general population is good at threshold breaking. Anti-lock breaks are a lot better for stopping than non-anti-lock breaks, if you lock your wheels. It's that whole static- versus dynamic-friction thingy.
And as for airbags and seatbelts causing injuries in crashes, it's true. They can. But guess what: it's statistically impossible for auto-makers to install saftey features that protect every possible driver from every possible impact. (well, the one saftey feature that would work is the "car-with-no-engine" feature. It never gets into accidents). So clearly, if airbags and seatbelts save more lives than they cost, they are worth having. And if you're so small that your airbag is always a danger to you, you can have it disabled (I have a friend, who is a dwarf, and her airbag is disabled, with a key, so that if a normal-sized person drives her car, it can be turned back on).
Just because a potential technology has a downside doesn't mean it's worthless and we should shun it. Nothing is free; just do the cost-benefit analysis and pick whichever has the best ratio.
Clue sticks can't solve all humanity's problems; we're too far gone as a species for that. But if you can have an automated tool enforce the rules, why not use it? Admit it: Generics make it easier to understand the code, because you are always sure of what you get. Nobody is FORCING you to use generics. But if you do use them, your code will be more readable, even if you are a lousy programmer.
Yes. But not everything is covered. Dental work, for example, is not (at least, not fully covered). Many full-time employees have dental benefits, though.
It's a bit of a catch-22, isn't it? If I write standards-compliant code, and no browsers support my standard, then my site is useless. If enough sites are useless, customers will complain that they can't reach the sites they want. But meanwhile, my site is useless and thus I don't get paid. So I write a site that works, even if it's not standards compliant, and then nobody complains, so browsers don't need to support the standard.
The key is that a standard is only as good as the implementations of it. Even if the NEXT version if IE or Moz or Konq is so great that it supports all standards you care about, there are still going to be so many people who are unable to use that next version of the browser. So they use an older one, that still works. So, if I care about those people, I have to support them. That's how things work; that's why computer systems get crufty. And that's why people use HTML tables for positioning, or javascript when they should use CSS (or vice-versa).
If everybody coded according to the standards, there would be nothing on the internet worth seeing, since most browsers don't follow the standard. I like standards as much as the next guy, but software is a business, and people write websites to solve problems and satisfy customers/users. If your website is standards compliant, but not usable by your target market, your fanaticism costs you your customer. Web developers can't just close their eyes and say "I will only follow standards!" To think so is naive.
I agree that KJA uses superweapons way too much. However, the plot-lines of Jedi Acadamy were much simpler than the Zahn books and would probably be more easily made into a movie. I bet you could turn that whole trilogy into one movie, and it'd actually be BETTER for it.
Well, I'd love to, but I'm busy that day. But seriously, I know how you feel about the old-computers home. I have several that are waiting for a yard sale next summer:)
yeah, I figure it's a hardware fault. Though it could be because she upgraded ICQ recently. In any case, the machine is so old that it wasn't worth thinking about it. I just bought her a new one:)
The Linux kernel may not crash, but the parent's point was that long uptime means no reboots for software patching. Some things can be patched without a reboot, but there's a long-standing kernel bug where any program can become root... probably time to reset those long uptimes, I think.
Also, I, and many of my friends, still run Windows 98. It's quite stable. Not rock-solid, but I rarely get crashes. My wife's computer, running '98, started getting really flakey. But was that because the hardware was failing? Maybe. In any case, I've had Windows 98 running for a long time. I don't usually reboot my computer at home unless I have to. I went about 4 months without rebooting '98 once. I found that my stability depended almost entirely on the quality of my NVidia video drivers, since they were invariably the component that failed, requiring a reboot.
I used to get a sore spot in the middle of my palm from holding those oh-so-ergonomic Atari joysticks.
Also, I used to have really bad keyboard posture when playing Doom: the keyboard on the edge of the table, my palms against the edge, and my fingers on the ctrl-alt and arrow keys. Not good for the ol' wrists and fore-arms.
What I think is odd is how some people attribute the comments of some Slashdot posters to the whole community of Slashdot readers. I read Slashdot. Yet I also respect music copyright. I own many CDs. I also respect software copyright. Is this a contradiction? Not if you understand that Slashdot is actually a forum where the posters have more than one opinion.
Well, I have only one point to make in response to your comment about your project. In general, a programming language doesn't have anything to do with code maintenance. A well-written C program will be just as easy to maintain as a well-written java program or a well-written php program. However, some programming environments (like java) provide/enforce certain features for organizing code which helps. But in the end, it's up to the developers to write properly organized code, that does the job right.
I've seen java products that succeeded and java products that failed, and it's not usually Java that decides the difference. However, I have noticed that programs written quickly, in order to get to market faster, usually suffer from having too many corners cut in the design and implementation. These affect long-term maintainability more than the choice of the language.
Java can help you get to market faster (than, say, C) by eliminating certain kinds of bugs, like memory bugs, and by providing a set of tools (like the Java class libraries) to help you write business code. But in the end, the programmers are responsible for writing the code you have to maintain.
Slashdot Mirror
The thing is, Linux CAN support sound-cards. Sound-card support has been around since I started using Linux in '97, and it wasn't new then. The problem is that not all cards work in Linux. There is only one reason for this:
Hardware vendors still do not care about Linux.
There are some vendors who care, and their stuff is supported. Creative Labs even open-sourced the SB Live/Audigy driver (they probably aren't the only one, but that's what card I have, so I know that one's available). So Creative cards work great... just load Linux, and there it goes.
Linux on the desktop is not impossible. In terms of functionality, Linux is equal to Windows in some areas, surpasses it in others, and lacks in some. That's to be expected; you could claim that Windows isn't ready for the desktop, look how much more usable Linux is for this or that! But that's not the point; people will use what they have as long as most things work most of the time.
The difference between, say, Windows 95 and OS/2 in 1995 was A) Microsoft's monopoly tactics that shut out OS/2, and B) Nobody supporting OS/2 anyway. So if you can't get hardware drivers for your OS/2 box, but you can for your Windows box, Windows must be better, right? OS/2 must not be ready for the desktop, right? It's the same thing now, with Linux. Linux is as good as Windows for most tasks that home users care about. In some, it's worse, in others, it's better. For installing supported hardware, it's easier in Linux than Windows (in my experience, working in a computer service dept, and using Linux at home). For partially supported hardware in Linux, it's usually easier in Windows. For unsupported hardware in Linux, it's obviously easier in Windows. But that's not Linux's fault.
How about, Christ generally didn't use violent means; in the end he gave up his life to make his point? At the time he was arrested he had enough followers to raise an army. So it's truly different from the Doom story.
Doom just caters to our tendencies to enjoy violence, and provides an arena for us to wallow in. The fact that there are "demons" is irrelevant; just replace "army of demons suddenly attacking" with "army of aliens suddenly attacking" or "army of terrorists suddenly attacking" and you have the same game with different sprites.
I asked the same question to a university prof I had who consulted for NASA and he claimed that many people at NASA actually do all their work in imperial measurements, and they actually tried to make the ISS an all-imperial system. Still I think it's rather stupid that they can't use the standard measurement system.
I'd say you can generally expect that people don't have an ancient version of a browser, but the proper thing to do is find out what your site-visitors are using so that you can code the site appropriately. If your target audience has a significant portion running Netscape 4, you're probably stuck supporting it.
Asking people to upgrade their browser IS a problem, for many people. For instance, at work my employer only lets me use the version of IE that's installed on my computer. I am certainly not allowed to upgrade it, nor am I even allowed to install mozilla or some other browser. A good website designer can't just look at what features are supported on SOME version of a popular browser, he/she has to look at what the expected clients will be using. So if a significant percent of your expected visitors are likely to be using IE 5, you can't rely on IE-6 features and expect them to be happy.
how are they attached to your Opteron? I didn't think they made PCI MFM controllers :)
Strangely, my Athlon 1700 has a 5.25" floppy drive in it :)
I have developed code of significance without unit testing, and I can assure you that the quality of that code was far inferior to the quality of the code developed with more attention paid to unit tests. In the projects I've worked on, sometimes the manager has made the decision to skip unit tests in order to concentrate on features. It's true that those features can be worked on at a faster rate, and seemingly completed sooner. But inevitably, the number of bugs found in QA, and the amount of time spent revising the code eats up any savings. Even if we break even, in terms of time (which, in my experience, would be a generous assumption), then the non-unit-tested project finishes at the same time but has no suite of tests to carry forward to the next version.
Furthermore, the benefits of testing are not just related to finding bugs sooner in the initial version. The tests can help influence the design of the code. I've written code where I ended up refactoring it completely while writing the tests, because the initial version, while it worked, didn't wasn't easily testable or had too many redundancies in the code. The quality of the run-time product was the same, but the source code improved dramatically just because I wrote tests for it.
Also, having the unit tests is a good way to ensure that bugs aren't introduced later. In short, the benefits are so high that, while I can imagine (and have actually done it) working on a project with no tests, it's not a task that I would welcome. It's similar to asking me to work on a task with no debugger, or no source-code control system. Yes, it's possible, and heck, the Linux kernel was written without either of these things, but realistically these are vital tools for software development. To me, unit tests are another of those vital tools.
Isn't there an X server that's designed for testing? Or, perhaps you could write a simple application that interacts with your window manager, and your application can ask the window manager to do something, and then verify the result.
But you're in the arena of gui testing, which is hard. Everyone admits that it's hard. But for many applications, you can separate the gui from the parts that do the real work, and then test those parts. In some cases this can even give you a huge benefit in terms of program architecture, making it easier to maintain, upgrade and port.
I think if you're creative you'll find a way to test your application. And if not, you could consider writing a fake X server. It might be worthwhile looking at one that can be easily modified or controlled. Perhaps one of the Java X servers could do the trick, since it's easy to integrate one java program into another.
Where I work, unit tests are a requirement, not a luxury. WIthout fail, the projects with the most unit tests have the fewest bugs, and the projects with the fewest unit tests have the most bugs. I'm not exagerating.
My question to you is, if you have no unit tests, how can you be sure that the code works at all? Manual testing? Do you cover all the code paths with manual testing? It must take forever, or your application is rather trivial.
Supermount is more like automount than autorun. It's like automount for removable media. Baiscally, your removable media is always "mounted" as type supermount, and when you access it, supermount accesses the actual device, so the user can insert/remove media and supermount magically handles it. I'm not sure what happens if the user replaces the media while it's in use, since I've never tried that :)
It's not that people can't handle a different software package. They can, if they have to. But any time spent learning that new tool, or re-writing macros, or working around limitations in that tool is time that could be spent doing real work. All of that has to be factored into the cost of switching. In my job, I am required to work in Java or C++, depending on what project I'm working on. I don't get to whine, I just do what I have to. Each has its strengths and weaknesses, but I am forced to use one or the other depending on the task. But for my office correspondence? It's MS Word. It's there, I use it, I get stuff done. (Though I prefer Word Perfect, myself). Any time not spent messing around with my word processor is time I can spend coding. If my company were to switch to another word processor, they'd have to take into account all the time I, and my other coworkers, would spend messing around with the new program instead of coding. That's the cost of switching.
Ah, but did your friend's car also have the no-engine saftey feature? Clearly it should be mandatory for all cars :)
Anti-Lock brakes, they actually increase breaking distance and if you pump them (like anyone over the age of 26 was trained to do) you are screwed.
Anti-lock breaks increase stopping distance over properly-executed threshold breaking, but I think it's terribly naive to claim that the general population is good at threshold breaking. Anti-lock breaks are a lot better for stopping than non-anti-lock breaks, if you lock your wheels. It's that whole static- versus dynamic-friction thingy.
And as for airbags and seatbelts causing injuries in crashes, it's true. They can. But guess what: it's statistically impossible for auto-makers to install saftey features that protect every possible driver from every possible impact. (well, the one saftey feature that would work is the "car-with-no-engine" feature. It never gets into accidents). So clearly, if airbags and seatbelts save more lives than they cost, they are worth having. And if you're so small that your airbag is always a danger to you, you can have it disabled (I have a friend, who is a dwarf, and her airbag is disabled, with a key, so that if a normal-sized person drives her car, it can be turned back on).
Just because a potential technology has a downside doesn't mean it's worthless and we should shun it. Nothing is free; just do the cost-benefit analysis and pick whichever has the best ratio.
Clue sticks can't solve all humanity's problems; we're too far gone as a species for that. But if you can have an automated tool enforce the rules, why not use it? Admit it: Generics make it easier to understand the code, because you are always sure of what you get. Nobody is FORCING you to use generics. But if you do use them, your code will be more readable, even if you are a lousy programmer.
Yes. But not everything is covered. Dental work, for example, is not (at least, not fully covered). Many full-time employees have dental benefits, though.
It's a bit of a catch-22, isn't it? If I write standards-compliant code, and no browsers support my standard, then my site is useless. If enough sites are useless, customers will complain that they can't reach the sites they want. But meanwhile, my site is useless and thus I don't get paid. So I write a site that works, even if it's not standards compliant, and then nobody complains, so browsers don't need to support the standard.
The key is that a standard is only as good as the implementations of it. Even if the NEXT version if IE or Moz or Konq is so great that it supports all standards you care about, there are still going to be so many people who are unable to use that next version of the browser. So they use an older one, that still works. So, if I care about those people, I have to support them. That's how things work; that's why computer systems get crufty. And that's why people use HTML tables for positioning, or javascript when they should use CSS (or vice-versa).
If everybody coded according to the standards, there would be nothing on the internet worth seeing, since most browsers don't follow the standard. I like standards as much as the next guy, but software is a business, and people write websites to solve problems and satisfy customers/users. If your website is standards compliant, but not usable by your target market, your fanaticism costs you your customer.
Web developers can't just close their eyes and say "I will only follow standards!" To think so is naive.
I agree that KJA uses superweapons way too much. However, the plot-lines of Jedi Acadamy were much simpler than the Zahn books and would probably be more easily made into a movie. I bet you could turn that whole trilogy into one movie, and it'd actually be BETTER for it.
Well, I'd love to, but I'm busy that day. But seriously, I know how you feel about the old-computers home. I have several that are waiting for a yard sale next summer :)
yeah, I figure it's a hardware fault. Though it could be because she upgraded ICQ recently. In any case, the machine is so old that it wasn't worth thinking about it. I just bought her a new one :)
The Linux kernel may not crash, but the parent's point was that long uptime means no reboots for software patching. Some things can be patched without a reboot, but there's a long-standing kernel bug where any program can become root... probably time to reset those long uptimes, I think.
Also, I, and many of my friends, still run Windows 98. It's quite stable. Not rock-solid, but I rarely get crashes. My wife's computer, running '98, started getting really flakey. But was that because the hardware was failing? Maybe. In any case, I've had Windows 98 running for a long time. I don't usually reboot my computer at home unless I have to. I went about 4 months without rebooting '98 once. I found that my stability depended almost entirely on the quality of my NVidia video drivers, since they were invariably the component that failed, requiring a reboot.
I used to get a sore spot in the middle of my palm from holding those oh-so-ergonomic Atari joysticks.
Also, I used to have really bad keyboard posture when playing Doom: the keyboard on the edge of the table, my palms against the edge, and my fingers on the ctrl-alt and arrow keys. Not good for the ol' wrists and fore-arms.
What I think is odd is how some people attribute the comments of some Slashdot posters to the whole community of Slashdot readers. I read Slashdot. Yet I also respect music copyright. I own many CDs. I also respect software copyright. Is this a contradiction? Not if you understand that Slashdot is actually a forum where the posters have more than one opinion.
Well, I have only one point to make in response to your comment about your project. In general, a programming language doesn't have anything to do with code maintenance. A well-written C program will be just as easy to maintain as a well-written java program or a well-written php program. However, some programming environments (like java) provide/enforce certain features for organizing code which helps. But in the end, it's up to the developers to write properly organized code, that does the job right.
I've seen java products that succeeded and java products that failed, and it's not usually Java that decides the difference. However, I have noticed that programs written quickly, in order to get to market faster, usually suffer from having too many corners cut in the design and implementation. These affect long-term maintainability more than the choice of the language.
Java can help you get to market faster (than, say, C) by eliminating certain kinds of bugs, like memory bugs, and by providing a set of tools (like the Java class libraries) to help you write business code. But in the end, the programmers are responsible for writing the code you have to maintain.