I know it's business, but I still find it close to fraud..
Many of the customers know what they don't know, and will rely on the advise of the sales person, on the general assumption that at least *they* know the stuff.
The part that's horribly wrong is that the sales people generally knows just as little as the customer, and just go by what will make them most money, often not even thinking about the customer. And I find it doubly insulting that a person that *knows* the stuff, and can give really good advice try to wring even more money out of the poor victi^H^H^H^H^Hcustomer.
Luckily, I live in norway, and while there's much of the same attitude among the salesmen, it hasn't gone to the same level as USA seem to be, and I haven't (yet) been asked about anything remotely like the service plans. At least, I can't remember anything like that;-)
The day I'll have to explain to a sales person why I don't want extra warranty, is the day I stop buying there. The day I meet anything like the stories I've read here (people pestering you, having to have long discussions with 3-5 persons WHY I don't want it), is probably the day I get jailed for violence....
The problem is that the sound drivers don't do software mixing, and most soundcards can't do hardware mixing.
In addition to that, there's two standards, Open Sound System (/dev/dsp) and ALSA (/dev/snd/*). ALSA is the standard now, and it can emulate OSS, so that's usually perfect. IIRC ALSA can be set up to do software mixing through JACK.
But the usual way to do things is to go through a sound mixer daemon that takes care of stuff. One popular is called esd (EsounD - the gnome sound daemon), and another popular is alsa, the KDE daemon.
So some programs will try to use OSS, some will try to use ALSA, some esd(most gnome apps), some arts (kde apps). Very annoying, I know.
My way to solve this have been to 1. Standardize on alsa. Everything that can play to alsa, should do it. 2. Configure alsa to close after 10 seconds without input (done in the KDE control panel, under sound system) 3. Set esd to autostart, and close after 5 seconds with no input (/etc/esound/esd.conf) 4. Set xmms to alsa, and use the second channel on my card, so I have seperate volume control and can play music no matter what;-)
Nowadays, if I don't try to jump right from one app making noise to another using another system, I dont even notice things. It's not perfect, but it's quite usable.
None are "the best", because people are individual, not one big thing. What's best for one, can be horrible for another. Some people want drool-candy all over the place and bright colors, some want a big-ass frame-buffer for their terminal. Some want everything readily avaliable, preinstalled and preconfigured, some want to do everything by hand and have perfect control over what's happening on their system.
about the processor/ram thingy, I've seen the exact opposite. A friend of mine have a P3 600 mhz, ~400 mb ram, and nvidia card. I have a tbird 1.35 ghz, ~640 mb ram, and nvidia card. Both feel almost exactly the same to use. (CPU intensive tasks does of course take more time - but the "feel" is the same). I also tried linux on a duron 800mhz with 128 mb ram and nvidia card. PAIN. LOTS OF PAIN.
My conclusion is that linux loves ram, and dont care much about the CPU.
"WinXP runs cleaner/faster than Gentoo+ion3. I mean, there is something very wrong going on with Linux desktop."
Or with your setup. Since it goes against my experience with 5-6 systems, I'm guessing you're doing something screwy. Or have an ATi card:-p
That's funny. Except for the BIOS part, I'm actually doing that. I'm running Debian testing, and small updates for the entire system, from kernel to themes, comes out regularly.
And the best thing is, except for the internet connection, it's absolutely free.
Right now there's 110 new packages, and I can check description, file list, bugs, changelog, install an older version, hold it on the current version and more with just a few mouseclicks.
Uh.. I usually mentally filter out buzzwords when I read something.
After looking over it, I realized that the only thing I've read was "But as we will see, the ", and I had to slowly re-read the whole thing to get any meaning out of it (it didn't help, but it gave me a headache).
Don't ever do something like that to me again, please:-(
Shouldn't some simple sandboxing fix this? Like adding a limited user account just to run things like that on it?
On linux it should be pretty easy. 1. new user with home in/tmp - tmp gets deleted on boot. 2. recreate/tmp home directory when needed. 3. run a nested X server (Xnest) with a simple WM (like flux), a large xterm, and the program executed in that xterm. 4. when xnest closes, kill all processes by that user
Something like that should be easy to do in windows too, and will make it a bit harder for the virus authors.
From my point of view this looks extremely easy, any reason for why it haven't been done yet?
t said, you'll have to expend a lot less effort if you switch the desktops to Linux, until enough people follow suit that the crapware writers start to target it; then you'll find your users installing all sorts of crap again.
Uh. Yeah. In windows you'll have to do hard stuff, like visiting a site, or run an email attachment. In linux, all you have to do is just "Download this file, go into terminal and cd to the directory you downloaded it to, and write chmod +x file &&./file" - as simple as that.
Of course, all self-respecting BOFH's will instantly set noexec on the/home partition and set the shell to/bin/false.
It will be interesting to see how crapware will target linux.
Actually, with debian, dpkg does that for you. It basically says: "I found these programs running that might have a problem if they're not restarted. Can I restart them? [Y/n]" And then you push enter, and live happily ever after.
Note: This only restarts the main servers, not forks, so for example your ssh session will not be disturbed
I assume you've taken the time to actually read the apt howto to see if it can solve your problem, and especially the page http://www.debian.org/doc/manuals/apt-howto/ ch-apt -get.en.html#s-default-version
Of course it's possible, you just don't let anyone use the machine.
Therefore, by 2011 they've created an OS that goes directly to BSOD on boot, and never even checks the keyboard and network cards.
This will of course revolutionize the way we use computers, and will finally get rid of the driver hell we currently have.
Hey, I actually re-read that part multiple times, since it was kinda vague. He didn't say why, or even if it had something to do with the installation tests to do at all (and nowhere even implied that it was because of linux. It could just as well been because of windows the way it was described there).
After studying it a while, I guessed that he had some (independent) hardware problems, and needed to change the motherboard to get the machine running.
I would love to get a clarification from the author as to exactly why he needed a new motherboard.
What's really amusing about all this is how people jump to the conclusion that fits their ideas the most. I always find it fascinating to see the human mind at work like this:-)
A friend of mine had similar problems with RedHat(or Fedora - dont remember exactly) install on his laptop.
He got it running on vesa, but didn't like it, as it ran very slowly. So he tried to download ATI's drivers (just as you would do in windows). The shock came when ATI's own linux drivers didn't support the card (He later found a 'hacked' driver that worked - hacked here being putting the card ID in the driver's list of supported cards).
Now, if it was Windows, and ATI's drivers didn't support their own card, no one would even think of putting the blame on Windows itself. But under linux.. Well, it just HAVE to be linux' fault. Of course. What else could it be?
Another one (which I don't remember the url to, talked a bit with one of the developers - its still in beta) also automatically merged with the local package management (like getting deps, regging as a package), and also supported user-only installation transparently.
The real problem (as I see it) is that few or none are using them.
Slashdot Mirror
I know it's business, but I still find it close to fraud..
;-)
Many of the customers know what they don't know, and will rely on the advise of the sales person, on the general assumption that at least *they* know the stuff.
The part that's horribly wrong is that the sales people generally knows just as little as the customer, and just go by what will make them most money, often not even thinking about the customer.
And I find it doubly insulting that a person that *knows* the stuff, and can give really good advice try to wring even more money out of the poor victi^H^H^H^H^Hcustomer.
Luckily, I live in norway, and while there's much of the same attitude among the salesmen, it hasn't gone to the same level as USA seem to be, and I haven't (yet) been asked about anything remotely like the service plans.
At least, I can't remember anything like that
The day I'll have to explain to a sales person why I don't want extra warranty, is the day I stop buying there. The day I meet anything like the stories I've read here (people pestering you, having to have long discussions with 3-5 persons WHY I don't want it), is probably the day I get jailed for violence....
Jesus H. AntiChrist!
"my co-workers would say it's the customer's fault for not doing research for themselves"
-What the hell are you people doing there, then? Too busy robbing folks, I presume? (Or maybe I'm just too old-fashioned?)
The problem is that the sound drivers don't do software mixing, and most soundcards can't do hardware mixing.
;-)
In addition to that, there's two standards, Open Sound System (/dev/dsp) and ALSA (/dev/snd/*). ALSA is the standard now, and it can emulate OSS, so that's usually perfect. IIRC ALSA can be set up to do software mixing through JACK.
But the usual way to do things is to go through a sound mixer daemon that takes care of stuff. One popular is called esd (EsounD - the gnome sound daemon), and another popular is alsa, the KDE daemon.
So some programs will try to use OSS, some will try to use ALSA, some esd(most gnome apps), some arts (kde apps). Very annoying, I know.
My way to solve this have been to
1. Standardize on alsa. Everything that can play to alsa, should do it.
2. Configure alsa to close after 10 seconds without input (done in the KDE control panel, under sound system)
3. Set esd to autostart, and close after 5 seconds with no input (/etc/esound/esd.conf)
4. Set xmms to alsa, and use the second channel on my card, so I have seperate volume control and can play music no matter what
Nowadays, if I don't try to jump right from one app making noise to another using another system, I dont even notice things. It's not perfect, but it's quite usable.
None are "the best", because people are individual, not one big thing. What's best for one, can be horrible for another. Some people want drool-candy all over the place and bright colors, some want a big-ass frame-buffer for their terminal. Some want everything readily avaliable, preinstalled and preconfigured, some want to do everything by hand and have perfect control over what's happening on their system.
Let me guess.... You have an ATi card?
:-p
about the processor/ram thingy, I've seen the exact opposite. A friend of mine have a P3 600 mhz, ~400 mb ram, and nvidia card. I have a tbird 1.35 ghz, ~640 mb ram, and nvidia card. Both feel almost exactly the same to use. (CPU intensive tasks does of course take more time - but the "feel" is the same).
I also tried linux on a duron 800mhz with 128 mb ram and nvidia card. PAIN. LOTS OF PAIN.
My conclusion is that linux loves ram, and dont care much about the CPU.
"WinXP runs cleaner/faster than Gentoo+ion3. I mean, there is something very wrong going on with Linux desktop."
Or with your setup. Since it goes against my experience with 5-6 systems, I'm guessing you're doing something screwy. Or have an ATi card
Been there, done that, seen the movie. Try doing that with a user account in linux.
That's funny. Except for the BIOS part, I'm actually doing that. I'm running Debian testing, and small updates for the entire system, from kernel to themes, comes out regularly.
And the best thing is, except for the internet connection, it's absolutely free.
Right now there's 110 new packages, and I can check description, file list, bugs, changelog, install an older version, hold it on the current version and more with just a few mouseclicks.
"Adventures of ... something... in the land of BASIC"
Now THAT's a horror story if I ever saw one
Uh.. I usually mentally filter out buzzwords when I read something.
:-(
After looking over it, I realized that the only thing I've read was "But as we will see, the ", and I had to slowly re-read the whole thing to get any meaning out of it (it didn't help, but it gave me a headache).
Don't ever do something like that to me again, please
Ah, but that is simple, my friend. Carrier pigeons.
w w.blug.linux.no/rfc1149/
http://www.faqs.org/rfcs/rfc1149.html
http://w
See?
Shouldn't some simple sandboxing fix this? Like adding a limited user account just to run things like that on it?
/tmp - tmp gets deleted on boot. /tmp home directory when needed.
On linux it should be pretty easy.
1. new user with home in
2. recreate
3. run a nested X server (Xnest) with a simple WM (like flux), a large xterm, and the program executed in that xterm.
4. when xnest closes, kill all processes by that user
Something like that should be easy to do in windows too, and will make it a bit harder for the virus authors.
From my point of view this looks extremely easy, any reason for why it haven't been done yet?
Extensive research shows that snow usually feels cold.
Hmm, yes, it's probably a well-packaged library.. Don't know if dpkg have enough meta-info to do such things, actually..
Yes, the technically best products always win, that's why we've all been using beta video players until the DVD format came out.
hey, wait a minute....
t said, you'll have to expend a lot less effort if you switch the desktops to Linux, until enough people follow suit that the crapware writers start to target it; then you'll find your users installing all sorts of crap again.
./file" - as simple as that.
/home partition and set the shell to /bin/false.
Uh. Yeah. In windows you'll have to do hard stuff, like visiting a site, or run an email attachment.
In linux, all you have to do is just "Download this file, go into terminal and cd to the directory you downloaded it to, and write chmod +x file &&
Of course, all self-respecting BOFH's will instantly set noexec on the
It will be interesting to see how crapware will target linux.
dude, don't use telephones
(yah, its a joke)
Actually, with debian, dpkg does that for you. It basically says:
"I found these programs running that might have a problem if they're not restarted. Can I restart them? [Y/n]"
And then you push enter, and live happily ever after.
Note: This only restarts the main servers, not forks, so for example your ssh session will not be disturbed
"When all you have is a hammer.."
/ ch-apt -get.en.html#s-default-version
Apt can perfectly fine use mixed stable/testing.
I assume you've taken the time to actually read the apt howto to see if it can solve your problem, and especially the page
http://www.debian.org/doc/manuals/apt-howto
Of course it's possible, you just don't let anyone use the machine. Therefore, by 2011 they've created an OS that goes directly to BSOD on boot, and never even checks the keyboard and network cards. This will of course revolutionize the way we use computers, and will finally get rid of the driver hell we currently have.
So you're saying he isn't a user because he is geeky?
Yes. I can even install the new nvidia drivers for my GeForce without rebooting. Try that in windows.
Hey, I actually re-read that part multiple times, since it was kinda vague. He didn't say why, or even if it had something to do with the installation tests to do at all (and nowhere even implied that it was because of linux. It could just as well been because of windows the way it was described there).
:-)
After studying it a while, I guessed that he had some (independent) hardware problems, and needed to change the motherboard to get the machine running.
I would love to get a clarification from the author as to exactly why he needed a new motherboard.
What's really amusing about all this is how people jump to the conclusion that fits their ideas the most.
I always find it fascinating to see the human mind at work like this
A friend of mine had similar problems with RedHat(or Fedora - dont remember exactly) install on his laptop.
He got it running on vesa, but didn't like it, as it ran very slowly. So he tried to download ATI's drivers (just as you would do in windows). The shock came when ATI's own linux drivers didn't support the card (He later found a 'hacked' driver that worked - hacked here being putting the card ID in the driver's list of supported cards).
Now, if it was Windows, and ATI's drivers didn't support their own card, no one would even think of putting the blame on Windows itself.
But under linux.. Well, it just HAVE to be linux' fault. Of course. What else could it be?
Just want to add the url to the other one I mentioned, and hang a name to it.
:-)
Autopackage. http://www.autopackage.org/
also, it seems like I misunderstood a bit about the package integration part. It's in the todo, at least
The problem isn't that it's no unified installer.
The problem is that it's (in good ol' linux tradition) quite a lot of them around.
http://zero-install.sourceforge.net/ looks very interesting.
Another one (which I don't remember the url to, talked a bit with one of the developers - its still in beta) also automatically merged with the local package management (like getting deps, regging as a package), and also supported user-only installation transparently.
The real problem (as I see it) is that few or none are using them.