The playing field may not be level (and, in fact, is not, as you correctly recognize), but you'll get a lot further by working to compensate for that fact than by complaining about how unfair reality is. Actually, we're doing both.
Linux compatibility is getting better all the time. Despite a moving target, we're actually getting better and faster at writing good, stable drivers.
But if you come around complaining that some random hardware isn't supported, especially if you're claiming it's a "usability" issue, I think it's fair to point out that we are going above and beyond what Windows does for you with device compatibility. That we're not there yet doesn't mean there's no focus, and bitching about it doesn't help.
Back when I used it, it was a complete Windows rip. Again: maybe, in its default configuration.
Does Windows have virtual desktops? No. Does Windows have more than one panel? No. Does Windows even have the ability to do that menu-bar-across-the-top thing? Hells no.
Out of the box, Ubuntu configures KDE to look and feel like Windows, for obvious reasons. (GNOME ends up being more of a hybrid; it looks a bit like OS X and a bit like Windows, and a bit like something else.) But scratch the surface, and there's a lot of configurability there that simply doesn't exist in any other OS -- at least, in KDE. (GNOME would rather force you into the One True Way of doing things; they're worse than Apple sometimes.)
There are numerous of these "use it maybe once a year" features that need to be discoverable. And I wouldn't mind if all of them took an hour to discover, because I'd rather waste a few hours every year than waste, on average, an hour or so every few days because of a UI that is discoverable, but not usable.
I'd argue that Ubuntu doesn't focus on usability much when it didn't support my wifi or laptop's sleep mode. Do you realize that if the same thing happened on Windows, you'd blame your wifi or laptop manufacturer?
That said, it's been a couple years. A lot has changed, especially in the realm of hardware compatibility -- though I suspect it wouldn't work on your tablet, I very much doubt it would screw up your Vista. (Would that be such a loss, anyway?)
That really sounds a lot more like five years ago, and on Gentoo.
Now, it's pretty much like driving a real car. You want to install a program? Click "Add/Remove Programs". Want to visit a web page? Click "Web browser", then type it in and go.
And just like a car, it will drive you right into a tree if you ask it to. Occasionally, it's smarter about that -- "Are you sure you want to delete/?"
Oh, and by the way: Yes, cars have gotten better. That doesn't mean people always blamed the cars when they weren't -- if you drive a manual today, and you stall out every five feet, is that the car's fault, or yours?
OP's dad might bang his thumb accidentally with the hammer but he ain't gonna think to himself "man I should get some training on this thing before I do myself an injury" because he'll know what he did wrong right away. Fair enough. But there's a fairly large class of machinery -- like, say, cars -- for which you'd better get some training right now, because you can't afford to learn the hard way.
That's not because cars have stupid designers, it's just the nature of the beast. You can make pretty much 100% safe bumper cars (and you still need supervision); you can't make 100% safe real cars. You can make 100% intuitive, simple, and safe kiosks; you can't make 100% usable and safe desktop computers.
Getting caught with books on murder, evading police surveillance, having a front seat removed from your car, soaked in 3 inches of water? None of which is evidence of anything other than being a piece of work, which is not, in itself, illegal. And let's not forget the serial killer Nina was having an affair with.
I cannot believe you're actually arguing for "guilty until proven innocent."
FOSS fundamentalism - "MP3 codecs and DeCSS are unclean, so let's make it harder to use them". More like "MP3 codecs and DeCSS are illegal in the US, and we don't exactly have the political clout to change that. Let's let that be some third-party project in another country." And despite that, they're surprisingly easy to install.
I much prefer this kind of "fundamentalism" to, say, Canonical being sued out of business by the people who own the MP3 patents. "Fundamentalism" was not including the nvidia drivers -- but they do that now (though it is an extra click, they do guide you through it), so your argument is pretty much moot.
Windows users which think Add/Remove programs means Remove programs (because in Windows you can't Add any programs via this menu...). This, however, can be countered by having a package manager advertised properly. Finally, some sanity!
Yes, Add/Remove programs is correct, and should not be changed. The only solution here is to try to educate users -- any further handholding from the OS will just drive away experienced users.
Windows way of installing programs by downloading them from websites. This should be discouraged. But again, basic training such that the user understands what a package should look like -- find a.deb file, and install that.
Once Ubuntu is loaded with pretty wizards, no developers will use it ("build a system that an idiot can use, and only an idiot will want to use it"). There should be an "expert" mode which turns off all introductory wizards. What you need is a way for the introductory wizards to not be annoying, or be easily dismissed -- and then be easy to find again. Every user at some point really won't need that wizard. And sometime between now and then, they'll think they don't need it, and then discover that they really do need it.
Or, more importantly, they were complaints that it's both not like Windows, and doesn't read your fucking mind.
And as Clippy shows, trying to program a computer to read your mind is a bad idea. Believe it or not, there are some users who like Clippy; I'm going to ague that any Linux distro which focuses on those users is NOT going to be a good thing for the mainstream Linux-on-the-desktop goal.
The reason people keep making car analogies is that they're better than hammer analogies -- you want to go somewhere, not learn how to fix cars, but there's a bare minimum of training you need, and it'll take three months or so of Driver's Education (at least!) to get that right.
But even the hammer can work -- would your dad expect to be able to pick up a hammer and a nail, and, with no training at all, figure out how to drive it in -- or pull a nail out? He'd very likely bang his thumb once or twice. And when that happens, if he treated it like he treats the computer, he'd be screaming at the hammer -- "Why did you hurt me? Why are you so stupid?? The people who design hammers must never have used one..." No, the smart thing to do is ask someone who knows how to use a hammer to teach you.
The same KDE that uses single-click everywhere by default, that has an optional Mac-style menu bar... The same that, on Ubuntu, has a clearly OS X inspired control panel... That KDE?
And you're confusing "usability" with "discoverability". Discoverability is important for the first hour or two of using an OS, maybe the first few days. Usability is important for the rest of your life. I'm glad Ubuntu focuses on the latter.
I've just booted, and I have almost a gig used. Half of it is cache. I could run XP, but there's no way I'd run it all the time.
So I think you're right -- only a couple of people need Windows, therefore, either let them run it as a primary OS, or leave one Windows server running that they RDP into.
It sounds to me like DBC is much more closely related to strict type-checking than to unit testing (or any other kind of testing).
In other words, it's a subset of testing. I still don't see why I'd want it to be formally defined by the language, though I can see it being useful to have a DSL that's faster at writing the simplest test cases.
By the way: I generally do both kinds of tests. I write unit tests (mocking away what isn't related to this particular chunk of code) and more thorough tests (trying to get as close as possible to the way this object will actually be used). For a web app, for example, it's possible to get browser-based tests -- as in, tests that actually run in a real web browser and interact with your app.
But I would much rather have a flexible language in which it's possible to write DSLs, than a language in which certain kinds of tests are baked in as a DSL, and for others, you're on your own.
Of course, that's because "you" know what you're doing and would act the same, even using Windows. No, I wouldn't, because on Windows, there are no good package managers. Your best bet is to only install software that's good by reputation, and to do so from their domain -- meaning you're vulnerable to MITM attacks, etc.
All the attacker needs to do is wrap it in a.tgz file, where permissions are preserved. Making it now several more steps -- you still have to unpack the tarball, and double-click the files inside. That's a far cry from clicking an executable, and then "Open from current location" and you're done.
You're right that it's about secure users, but it's much easier to be a secure user on Linux, precisely because you would never download foo.exe -- or foo.sh, or whatever. For the most part, you get things through your package manager, or not at all.
As such, it is not particularly easy to download and run SomeFamousPersonNaked.bin -- you have to download it to somewhere, then you have to change its permissions, and then you have to run it -- and even then, they still don't have root.
However, for a very long time, an antivirus actually made some sort of sense on Windows, because you would have exploits from visiting a webpage or reading an email. You actually had a situation where the most security-conscious users would never use the Preview Pane, so that they could delete suspicious emails without looking at them. In that particular kind of insane world, it makes sense to have antivirus -- and that is precisely why antivirus seems so laughable now.
Probably one of the more interesting things David DeAngelo said was that it's a lot easier to turn a sexual relationship into a romantic one than the other way around.
Or, to put it another way,
A woman has a close male friend. This means that he is probably interested in her, which is why he hangs around so much. She sees him strictly as a friend. This always starts out with, you're a great guy, but I don't like you in that way. This is roughly the equivalent for the guy of going to a job interview and the company saying, You have a great resume, you have all the qualifications we are looking for, but we're not going to hire you. We will, however, use your resume as the basis for comparison for all other applicants. But, we're going to hire somebody who is far less qualified and is probably an alcoholic. And if he doesn't work out, we'll hire somebody else, but still not you. In fact, we will never hire you. But we will call you from time to time to complain about the person that we hired. Don't be that guy.
IBM is now the world's largest Linux vendor and the world's largest computing services company, and is not going away any time soon. Maybe that was your point? That, and that they were a large company which had to adapt quite a lot, or they wouldn't be here anymore.
Actually, I think that most of the corner cases are better solved with vmware. These days, running two operating systems at once is nothing. It's not "nothing", especially if you only use one of them 10% of the time. Why force an end-user to throw a gig or so of RAM at running another OS, if they only really need it for, say, IE?
It's cheap enough, yes, and there are cases where I see it working. But it should be optional, and I imagine a thin-client solution might be cheaper anyway. How much does it cost for an MS Terminal Server license vs, say, commercial virtualization and a copy of XP on every desktop? And that's assuming you need the real MS terminal server.
Unit testing is a very specific kind of testing: testing of isolated units. That's where the name comes from. And an entire program can be seen as an isolated unit. Conversely, the smallest of the "isolated" units you try to test are still going to be relying on something -- even if it's just the compiler and the language -- so you are always testing that something as well.
One of the key aspects of integration testing is that you are no longer writing tests only for functionality created by you or someone in your immediate organization. Which is exactly my point: You can never write tests only for functionality created by you or someone in your immediate organization, unless you are hand-coding assembly for your very own CPUs -- and you're smelting the metal for your own cases, etc.
Now, you might only be considering your own software when creating those tests, and that's fine. That's encouraged, especially when most of these units will have been tested individually already.
Let me put it this way:
def multiply_two_ints(a, b)
a * b end
def raise_int_to_positive_integer_power(a, b)
result = 1
b.times do
result = multiplyTwoInts(result, a)
end
result end
def factorial...
Been awhile since I had to do much mathematical code, but I think that demonstrates what I'm talking about: You simply do not have an isolated unit to test there. You could always mock up a multiplyTwoInts for that specific purpose -- one with a preset table of values, and an expectation of being called in a certain order -- but it's simpler to just write a "unit" test (that's really an integration/functional test in disguise) for raise_int_to_positive_integer_power.
And by the way, multiply_two_ints assumes the * operator does what it's supposed to.
No, I would never use function names like that -- but I'd also never write that function anyway.
So by the time you get to "When the user adds something to their shopping cart, it should persist there and update the total when they check out..." etc etc... You're still ultimately testing one unit (the entire app, maybe specifically the routing code), with the assumption that all the other units do what they're supposed to.
Knuth never says that he doesn't see ANY value in unit tests No, he said that they were "a waste of time." Did you read the article?
He also admits that parallel code can be useful for several applications. In the kind of grudging way that a Linux zealot might admit that Microsoft can be useful in certain situations. Here, let me quote the article for you:
During the past 50 years, Iâ(TM)ve written well over a thousand programs, many of which have substantial size. I canâ(TM)t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading. Surely, for example, multiple processors are no help to TeX. Which also shows a lack of imagination, by the way -- I can imagine how Tex could scale to multiple processors. The only reason multiple processors aren't a help is that any one today is more than fast enough.
And so he prefers "re-editable code" to code reuse. So what? Here in the modern software world, we have this concept of a thing called a "shared library."
I've read his arguments about "re-editable code", and I continue to believe that re-usable code is better, especially in a modern language where, without even trying, it's just about as flexible as going and editing the code in question. (Example: Ruby's open classes.)
Well, I don't hate him, but I don't respect him as much after this.
Basically, I can see why Knuth wouldn't need unit tests, in code he writes himself, that no one else will ever use. But to not see value in unit tests at all -- let alone multicores and code reuse -- tells me he is a dinosaur. A genius dinosaur, but a dinosaur nonetheless.
Slashdot Mirror
Probably is from Seinfeld. I first saw it on bash.org, anyway.
Can you source the Seinfeld quote, though?
It has an uninstaller. No, really.
Also: Windows XP, at least, was able to reinstall a bootloader from the CD. This is a valuable skill to have, regardless.
Linux compatibility is getting better all the time. Despite a moving target, we're actually getting better and faster at writing good, stable drivers.
But if you come around complaining that some random hardware isn't supported, especially if you're claiming it's a "usability" issue, I think it's fair to point out that we are going above and beyond what Windows does for you with device compatibility. That we're not there yet doesn't mean there's no focus, and bitching about it doesn't help.
Does Windows have virtual desktops? No. Does Windows have more than one panel? No. Does Windows even have the ability to do that menu-bar-across-the-top thing? Hells no.
Out of the box, Ubuntu configures KDE to look and feel like Windows, for obvious reasons. (GNOME ends up being more of a hybrid; it looks a bit like OS X and a bit like Windows, and a bit like something else.) But scratch the surface, and there's a lot of configurability there that simply doesn't exist in any other OS -- at least, in KDE. (GNOME would rather force you into the One True Way of doing things; they're worse than Apple sometimes.) There are numerous of these "use it maybe once a year" features that need to be discoverable. And I wouldn't mind if all of them took an hour to discover, because I'd rather waste a few hours every year than waste, on average, an hour or so every few days because of a UI that is discoverable, but not usable. I'd argue that Ubuntu doesn't focus on usability much when it didn't support my wifi or laptop's sleep mode. Do you realize that if the same thing happened on Windows, you'd blame your wifi or laptop manufacturer?
That said, it's been a couple years. A lot has changed, especially in the realm of hardware compatibility -- though I suspect it wouldn't work on your tablet, I very much doubt it would screw up your Vista. (Would that be such a loss, anyway?)
That really sounds a lot more like five years ago, and on Gentoo.
/?"
Now, it's pretty much like driving a real car. You want to install a program? Click "Add/Remove Programs". Want to visit a web page? Click "Web browser", then type it in and go.
And just like a car, it will drive you right into a tree if you ask it to. Occasionally, it's smarter about that -- "Are you sure you want to delete
Oh, and by the way: Yes, cars have gotten better. That doesn't mean people always blamed the cars when they weren't -- if you drive a manual today, and you stall out every five feet, is that the car's fault, or yours?
That's not because cars have stupid designers, it's just the nature of the beast. You can make pretty much 100% safe bumper cars (and you still need supervision); you can't make 100% safe real cars. You can make 100% intuitive, simple, and safe kiosks; you can't make 100% usable and safe desktop computers.
It is faster than Ruby 1.8.
However, it is running with the aid of Ruby 1.9 on the server, so I suspect that actual Ruby 1.9 is faster.
WINE does, in fact, run some programs faster than Windows 2000, at least. I haven't seen any comparisons to XP.
I cannot believe you're actually arguing for "guilty until proven innocent."
Does an attourney have the power to prevent that?
The first hit is free. As in 'without cost.'
I much prefer this kind of "fundamentalism" to, say, Canonical being sued out of business by the people who own the MP3 patents. "Fundamentalism" was not including the nvidia drivers -- but they do that now (though it is an extra click, they do guide you through it), so your argument is pretty much moot. Windows users which think Add/Remove programs means Remove programs (because in Windows you can't Add any programs via this menu...). This, however, can be countered by having a package manager advertised properly. Finally, some sanity!
Yes, Add/Remove programs is correct, and should not be changed. The only solution here is to try to educate users -- any further handholding from the OS will just drive away experienced users. Windows way of installing programs by downloading them from websites. This should be discouraged. But again, basic training such that the user understands what a package should look like -- find a
Or, more importantly, they were complaints that it's both not like Windows, and doesn't read your fucking mind.
And as Clippy shows, trying to program a computer to read your mind is a bad idea. Believe it or not, there are some users who like Clippy; I'm going to ague that any Linux distro which focuses on those users is NOT going to be a good thing for the mainstream Linux-on-the-desktop goal.
The reason people keep making car analogies is that they're better than hammer analogies -- you want to go somewhere, not learn how to fix cars, but there's a bare minimum of training you need, and it'll take three months or so of Driver's Education (at least!) to get that right.
But even the hammer can work -- would your dad expect to be able to pick up a hammer and a nail, and, with no training at all, figure out how to drive it in -- or pull a nail out? He'd very likely bang his thumb once or twice. And when that happens, if he treated it like he treats the computer, he'd be screaming at the hammer -- "Why did you hurt me? Why are you so stupid?? The people who design hammers must never have used one..." No, the smart thing to do is ask someone who knows how to use a hammer to teach you.
What, KDE?
The same KDE that uses single-click everywhere by default, that has an optional Mac-style menu bar... The same that, on Ubuntu, has a clearly OS X inspired control panel... That KDE?
And you're confusing "usability" with "discoverability". Discoverability is important for the first hour or two of using an OS, maybe the first few days. Usability is important for the rest of your life. I'm glad Ubuntu focuses on the latter.
Define "free".
I've just booted, and I have almost a gig used. Half of it is cache. I could run XP, but there's no way I'd run it all the time.
So I think you're right -- only a couple of people need Windows, therefore, either let them run it as a primary OS, or leave one Windows server running that they RDP into.
It sounds to me like DBC is much more closely related to strict type-checking than to unit testing (or any other kind of testing).
In other words, it's a subset of testing. I still don't see why I'd want it to be formally defined by the language, though I can see it being useful to have a DSL that's faster at writing the simplest test cases.
By the way: I generally do both kinds of tests. I write unit tests (mocking away what isn't related to this particular chunk of code) and more thorough tests (trying to get as close as possible to the way this object will actually be used). For a web app, for example, it's possible to get browser-based tests -- as in, tests that actually run in a real web browser and interact with your app.
But I would much rather have a flexible language in which it's possible to write DSLs, than a language in which certain kinds of tests are baked in as a DSL, and for others, you're on your own.
Kind of like syntactic vinegar.
You're right that it's about secure users, but it's much easier to be a secure user on Linux, precisely because you would never download foo.exe -- or foo.sh, or whatever. For the most part, you get things through your package manager, or not at all.
As such, it is not particularly easy to download and run SomeFamousPersonNaked.bin -- you have to download it to somewhere, then you have to change its permissions, and then you have to run it -- and even then, they still don't have root.
However, for a very long time, an antivirus actually made some sort of sense on Windows, because you would have exploits from visiting a webpage or reading an email. You actually had a situation where the most security-conscious users would never use the Preview Pane, so that they could delete suspicious emails without looking at them. In that particular kind of insane world, it makes sense to have antivirus -- and that is precisely why antivirus seems so laughable now.
Or, to put it another way, A woman has a close male friend. This means that he is probably interested in her, which is why he hangs around so much. She sees him strictly as a friend. This always starts out with, you're a great guy, but I don't like you in that way. This is roughly the equivalent for the guy of going to a job interview and the company saying, You have a great resume, you have all the qualifications we are looking for, but we're not going to hire you. We will, however, use your resume as the basis for comparison for all other applicants. But, we're going to hire somebody who is far less qualified and is probably an alcoholic. And if he doesn't work out, we'll hire somebody else, but still not you. In fact, we will never hire you. But we will call you from time to time to complain about the person that we hired. Don't be that guy.
(And by the way, chicks dig bash.org. Really.)
I find it hilarious that you're giving us dating advice with a sig like that.
Just saying...
It's cheap enough, yes, and there are cases where I see it working. But it should be optional, and I imagine a thin-client solution might be cheaper anyway. How much does it cost for an MS Terminal Server license vs, say, commercial virtualization and a copy of XP on every desktop? And that's assuming you need the real MS terminal server.
Now, you might only be considering your own software when creating those tests, and that's fine. That's encouraged, especially when most of these units will have been tested individually already.
Let me put it this way: Been awhile since I had to do much mathematical code, but I think that demonstrates what I'm talking about: You simply do not have an isolated unit to test there. You could always mock up a multiplyTwoInts for that specific purpose -- one with a preset table of values, and an expectation of being called in a certain order -- but it's simpler to just write a "unit" test (that's really an integration/functional test in disguise) for raise_int_to_positive_integer_power.
And by the way, multiply_two_ints assumes the * operator does what it's supposed to.
No, I would never use function names like that -- but I'd also never write that function anyway.
So by the time you get to "When the user adds something to their shopping cart, it should persist there and update the total when they check out..." etc etc... You're still ultimately testing one unit (the entire app, maybe specifically the routing code), with the assumption that all the other units do what they're supposed to.
I've read his arguments about "re-editable code", and I continue to believe that re-usable code is better, especially in a modern language where, without even trying, it's just about as flexible as going and editing the code in question. (Example: Ruby's open classes.)
Well, I don't hate him, but I don't respect him as much after this.
Basically, I can see why Knuth wouldn't need unit tests, in code he writes himself, that no one else will ever use. But to not see value in unit tests at all -- let alone multicores and code reuse -- tells me he is a dinosaur. A genius dinosaur, but a dinosaur nonetheless.