The problems are worse with the 2.6.14 kernel, not better... it just took awhile for them to start showing. I'm filing a bug report... hopefully it will help.
Well, perhaps it is indeed finally working... the ACPI messages describe the chipset by name now (VIA KT333), and are much more verbose about exactly what they're doing. I did think of the BIOS angle, and there have been no updates on this board in many, many moons. It was perfectly stable for me under Win2K as a desktop, a very nice board, and it stabilized nicely in noacpi mode. I do not think the board or the BIOS were at fault. I definitely haven't made any BIOS-level changes between then and now, so the increased verbosity leads me to believe that it now understands the chipset and will work. It didn't before, and mysteriously broke without any warning at all.
<rant> It should have, very clearly, told me that it didn't recognize the chipset it was on and that it was GUESSING at the settings. That would have saved me a couple of hundred bucks, because that would have been the first thing I'd have looked at, instead of replacing a functional drive. The total lack of any kind of reasonable error message whatsoever cost me. On top of that, this new changed behavior (suddenly noacpi doesn't work anymore) in a theoretically 'stable' line of kernels is pretty crappy. Freeze the features and go off and play in your own sandbox. When you're ready for testing, I'll happily jump in and start beating up on the RCs, once every 18 months or so.
I don't have time to do that every six weeks as yet more untested, unproven code is jammed down my throat along with the bugfixes I need to the LAST batch of untested, unproven code. I'll happily be QA once in awhile. I don't want to be QA all the damn time.
Right, I did think of that after I posted.... perhaps it is finally fixed. But APIC mode scares me... it's bitten me personally, and I've seen numerous (bad) stories about it from others. I didn't start out particularly worried about it (or anything else in 2.6, for that matter), but I sure ended up that way. And with Linus' reputed habit of doing invisible security fixes, falling back kernels isn't a good idea unless one absolutely must.
Maybe, just maybe, they've nailed it down and it finally works. I'm sure they'll get it eventually. But from past experience, I wouldn't want to bet very much money on any specific release being the likely candidate. They're not letting the old code stabilize. Instead of fixing bugs and having a 2.6 maintainer, they're constantly shoveling new features at us along with the bugfixes. Either we accept them, or the distro maintainers have to work furiously to backport the bug fixes to kernels that are obsolete, being 90 days old.
That's NOT the way to get a stable system. The old way of doing things, with a stable release that lasted longer than two months, worked pretty well. This method, in my not at all humble opinion, doesn't.
One of the core kernel crew, I believe it was Rik Van Riel, said that it was pretty much fine with him if only one 'stable' release in three was actually stable.
There are two main reasons to run GRUB. The first is because you can build new kernel start lines on the fly. LILO has to be hardcoded with kernel locations on disk. You can change the boot parameters, but you can't start random kernels. GRUB, on the other hand, understands enough of the filesystems on which it lives to allow you to boot arbitrary kernels on the fly.
The second reason (closely related) is that if, for some reason, the kernel files move around on disk (did you just restore from backup?), LILO blows up, and GRUB just works.
Either bootloader can be used safely to remember multiple different kernels for routine experimentation.
The Linux kernel has many features, but it has them at the expense of stability. This new kernel did not drive the network card properly on my server, an Athlon 1900+ on an ASUS K7V333. It complained about stuck interrupts.
To get it to run, I had to remove the 'noacpi' line from the kernel boot parameters. This makes me very nervous, because I ADDED it to fix a problem with the software RAID code on this machine. I got occasional, mysterious "ACPI error" messages in the system log, with no other explanation whatsoever. Then my RAID started failing routinely. One particular drive always failed, so of course I thought it was the drive, and replaced it. The new drive immediately started failing in exactly the same way.
Only by adding in the noacpi line was I able to use the system reliably. Now that noacpi no longer works, I may be backed into a corner... I may end up having to switch to some other server software I can trust. The Linux team's refusal to maintain old code without adding new features, just waving their hands in their air and saying that the distros will make it right, doesn't work for me. I already switched my firewall over to OpenBSD because I was tired of the incessant patching, security hole after security hole. On a CF-based system, that's a pain in the ass to administer. I haven't had to touch OpenBSD since I installed it, months ago.
I like features, but first and foremost I use open source software because it doesn't break. At least, for a long time, it didn't. The 2.6 kernel has directly cost me a couple hundred bucks, has had an absolute horde of problems ever since it shipped, and just failed for me YET AGAIN.
You may be impressed by all the whizbang features, but more and more, Linux is falling into the exact same trap that Microsoft has... shipping features instead of a solid product.
Probably the single best resource on the Net for kernel discussion is Linux Weekly News, www.lwn.net. The main editor, Jon Corbet, is a very rare breed, a lucid writer who more or less understands the internals of the Linux kernel. As far as I can tell, in the entire Linux universe, this consists of a population of exactly one.
LWN has been around a long, long time, and it's one of the best Linux sites on the Net. Don't be put off by the relatively simple site design. The content is second to none.
Most of the really good stuff is on a time delay. If you subscribe, you get access immediately. Otherwise, you have to wait a week or two. Please do subscribe if you like it. It's not very expensive, and it's important to support the really good resources. Linux Weekly News is one of them.
(I'm not affiliated with them, except that I send in money every month.)
I had no trouble at all plugging in two different multi-button Logitech mice to my Mac G4. It recognized most of the buttons without any software at all. The right and middle button, the scrollwheel, and the forward and back thumb keys all worked immediately. I believe only the middle thumb button on the MX1000 failed to register. With some Control Panel changes, it was easy to map Expose functions to whatever buttons I wanted.
I haven't tried anything but Logitech mice, but the Mac seemed fully aware of all the capabilities (except the one button.)
I was talking about the computer monitor, the 24" widescreen. I think the TVs have them too, but I'm not sure if they have as many.
Generally, the only way to see them is to display a solid white image, and then get very close to the monitor and look either in the middle or at 1/3 and 2/3 of the way down the screen. You're looking for very, very thin horizontal black lines. They're completely invisible in normal viewing... you have to really look to find them.
A Trinitron tube has thousands of tiny vertical wires to disperse/channel the electron beam. The horizontal wire is necessary to keep the vertical ones from moving. To see it, you generally have to know what you're looking for and explicitly try to find it... it's not at all obvious. That's the price you pay for the superior picture.
The really big 24" monitors have two wires, at 1/3 and 2/3 the way down the screen.
Refresh rate in an LCD spec is really what the receiving circuitry can handle/adapt to. It doesn't change how fast the actual LCD elements update. A CRT is constantly drawing the screen, left to right, top to bottom, X number of times per second. So the refresh rate is very important there.... the faster it goes, the less flicker. An LCD emulates this behavior, by letting the monitor update an internal buffer up to X times a second, where X is the maximum refresh rate it supports.
If I understand the technology correctly, LCDs do an instant update of every pixel on the screen simultaneously every 1/60th of a second. (possibly faster in the newer, sub-16ms LCDs). It just writes out whatever was most recently loaded into the buffer, meaning that if the monitor is running faster than 60hz, frames will get dropped. This could cause image tearing as well, though the monitor could do internal double-buffering to prevent that.
Well, I play on a Dell 2405FPW(16ms = 60fps), and it seems fine to me, though I'm certainly not (anymore) a terribly competitive FPS player. I used to play at 85hz on my CRT, and I'm at 60 now, and I don't really notice a difference. Maybe when I was younger it might have mattered.
I'm really quite impressed with how well this unit scales. Earlier LCD scaling was incredibly horrible. I think it must be actually scaling the images past the native 1920x1200 resolution and then sampling back down. It doesn't have hard edges, it sort of blurs. It's not as good as a CRT, but it's close. You can tell it's not native resolution if you look, but you have to LOOK. It's not instantly apparent.
LCDs have come a long, long way in the last three or four years.
I think that's changed in Unstable, and presumably Testing as well. Right after the current Stable shipped, I had a big hassle with updating keys, and complaints by my systems that packages were unsigned. It wasn't hard to fix, but the systems complained loudly until I did. So I don't think that particular objection applies anymore.
RedHat and Suse, as you point out, are the best-supported by Oracle... as far as I know, they're the only vendor that anyone really cares about.:-)
Well, from the standpoint of a programmer or an administrator, it's very good indeed at getting to destinations. For the stuff that I do professionally, Windows just doesn't cut it, at least not without adding in a lot of other stuff. Unix is very popular in the sciences too, for similar reasons.
As far as your particular goals go... I haven't done that much with video encoding, but I was under the impression that Linux was pretty good in that area? It's certainly very good at working with music files. For instance, I have all my music stored as CUE/BIN files. When I bought the Squeezebox2 (a great music player, btw), I found that it would natively support CUE/FLAC. So I took about 45 minutes to whip up a script to recurse through my entire directory hierarchy, encode to FLAC, and massage the CUE files to point to the new FLAC files instead of the WAVs. (took several days to actually run, but I just left it going under screen, so I didn't have to fool with it.) I would have had a hard time doing that under Windows.
I don't have personal experience here, but I'd assume that most of the video-encoding programs should work under Linux the same way. You could easily script something, for instance, to encode a raw dump whenever you saved one, even to several different formats if you needed that. That kind of thing is hard to do with a GUI... not impossible, but usually awkward.
I think, in reading over your post, that perhaps you haven't stepped up to the next level yet, which I didn't do until I was forced to use it full time. Linux gives you an awesome array of tools, but it's still mostly up to you to assemble them into what you need. But once you have cobbled together a script to do something, expanding it, or replacing pieces of it, becomes quite easy.
For years, I was poisoned by the Windows Way, which is basically "use other people's applications in the way they intended". Linux doesn't work that way, so much. I think it's when you realize you have an incredible amount of control, and that you can very often build your own custom solution to a problem in a fraction of the time it would take under Windows, that your productivity really starts going up.
I think trying to use Linux the same way you use Windows is a perfectly good first goal, but if you stop there, you'll never exceed your Windows productivity... in fact, you'll probably not even match it. I think that may be where you're stuck. Treat it like Windows and that's all you'll get out of it. Treat it like Unix, and you can do magic.
The single best piece of advice I can give you is to find people who use Linux a lot (and that you like) and hang out with them. An awful, awful lot of Unix is arcane lore, passed on from person to person.... powerful ways of approaching problems that aren't ever mentioned in the documentation. Unless you have a truly extraordinary mind, far better than mine, you'll find learning it on your own to be an uphill battle. It certainly was for me. Linux/Unix is a mindset as much as an OS, and it's much easier to learn it from people who already know it, rather than having to invent it all yourself.
First, you have to realize that I'm pretty geeky... my experience may not translate well to Grandma or Uncle Joe.
My transition was almost accidental. I'd taken on a new job administering a network of Linux servers. I was provided a Windows desktop and several spare machines that I could use for whatever.. the prior administrator had liked to tinker with things. The Windows machine proved to be unreliable, and I was unable to determine if the company had paid for my Windows license at the time, so I just installed Mandrake on a spare box. I'd originally intended it as a secondary machine, but I ended up being happy enough that I never switched back, at least for work. (I still run Windows at home, mostly for gaming.)
After getting past the initial learning curve, I felt more productive because I had instant access to a huge range of powerful utilities. One of them, interestingly, was the humble bash shell. After settling in permanently and learning how to script properly (which I had never actually done before, though I'd been using Linux for years...I'd just not needed the ability sooner), I was able to automate a great many administrative tasks. That would have been much harder with Windows. I would have needed Cygwin, which is essentially Unix anyway. And screen and ssh were incredibly useful as well. I don't mean just the basic command-line ssh, but the remote-command, piping, port redirection, and proxying capabilities. That kind of thing is harder to do in Windows, and you definitely have to pay for it. (unless, of course, you use Cygwin, but it's still not native to the platform in quite the same way. If you're going to use free software anyway, might as well do it right.)
From a desktop perspective, I prefer Evolution to any other email client I've tried. It has the look and feel of Outlook, but is all Unixy underneath, so gluing in other programs is trivial. Adding in spam detection took very little time, for instance, and cost nothing, quite unlike the commercial alternatives. I loved the sorting rules and the ability to transparently support multiple email aliases (so I could be postmaster, webmaster, support, and my 'real' email address, without having to think much about them.) And I prefered Konqueror to any other browser I'd used up to that point. It ran faster, had tab support, and just in general struck me as superior to IE, except when it failed to render something. Fortunately, that wasn't terribly common, and Mozilla was there when Konqueror couldn't handle it. (Firefox wasn't out at the time I was making the transition.) And I absolutely loved the High Performance Liquid theme in KDE.
Multiple workspaces was a big productivity boost once I figured out how to organize it.... web browsing in one screen, email in another, remote jobs in a third (abstracted with the 'screen' utility so I could check up on things from home if I wanted), music player, network monitoring, and various random things (nethack!) in a fourth.
It's been quite awhile, so my memory has dimmed, but I believe but the rough edges were mostly determining how to get the hardware configured. Screen resolutions were a real pain. Getting sound working properly was also hard, and then determining/shopping for the best program to use for the different available functions. (I had quite a bit of experience with server Linux, but desktop Linux was pretty new to me.) A lot of this stuff was hard simply because related settings were spread all over multiple screens... they were organized by how the software was built, rather than by how people thought about the problem. Even now, the interfaces to system configuration stuff tend to be much harder than they should be.
Overall, there just weren't any artificial barriers between me and the system. It was still easy to use, but it was easy without hiding the power underneath. Windows abstracts things but then makes it very hard to get down to brass tacks, past the abstractions. Linux isn't like that. If you want to see ho
If you're still reading this thread, I thought I'd mention that they just announced (I got the mail about 10 minutes ago) the Squeezebox3, which adds native WMA support and looks nicer. But it's back to the old $299 price for the wireless version, $249 wired. (SB2 is $249/$199). Same very, very high-quality components.
The new design is more vertical and cleaner. It still kind of reminds me of a clock radio, but it's nicer-looking than the VHS-tape clock radio style of the SB2.
Tell them to try LiveCDs first, just to tinker. They let you play with Linux with zero commitment. Just be sure to explain that a 'real' install will be a lot faster, because it runs from the hard drive.
When you're ready for a hard drive install, I've been recommending Mandrake/Mandriva for new users for several years now. I started using it in the 8.X series, and after a short readjustment period, it was a total Windows replacement for me. I felt a lot MORE productive on Mandrake than on Windows, once I'd figured it out. It had some rough edges, but overall worked very, very well.
I've used a lot of Linux desktops over the years (Ubuntu, Debian, Redhat up to the 7.X series, Slackware, SLS), and I've always thought Mandrake was the best. (though Ubuntu is pretty nice too... you might want to try both.)
I don't have any experience with Suse, because for a long time you had to pay to get the best install options. The free version was purposely awkward to install, so I never bothered with it. Suse's loss, too... I liked Mandrake and I've sent them, geeze, three or four hundred bucks by now, probably. I just didn't want to pay BEFORE seeing the product. Now that they're more GPL-ish, they may be a very good spot for new users to tinker. I'll download and play with this one and see what's up with it.
For your friends, though, definitely start them on LiveCDs. They're easy to use, cheap to download and burn, and if they aren't impressed, all they have to do is shut down and eject the CD.
Re:Watch a little more closely ...
on
Deep in the Core
·
· Score: 2, Insightful
True, but also keep in mind that there are things that might have been even better that we still haven't discovered for lack of funding. Research, particularly basic (non goal-oriented) research, pays enormous dividends. Even if it's defense-based, the ROI is so enormous that the discoveries routinely affect everyone. Yes, we get many knock-off products from defense research, but that does not mean that this is the best possible way to allocate research dollars.
If the real goal is the advancement of knowledge and the human condition, then researching how to build things rather than destroy them would probably be a better solution. We'll still get the side effects (hey, this new roofing material is superb for boot soles!), but the original intended effects will be more broadly beneficial.
With the regular full Workstation version (I have no need for Player, but I assume it works the same way), you choose, from a dropdown menu, a USB device that you would like to connect to the virtual machine. VMWare 'unplugs' it from the host OS, and plugs it into the guest OS, until you quit the program or detach the device again.
What I did was to attach my USB hub to the virtual machine, and then plug flash modules in and out. That works fine, so I presume you'd be able to hotplug anything else you wanted. The guest just needs to 'own' the hub.
I think in earlier versions, the mouse focus had something to do with hotplug events, but I *think* they have changed that to the above system.
If you can't attach the hub to the guest, I think you'll have to plug it into the host system first, and then attach it to VMWare. That will simulate a hotplug, and will probably work for most devices.... preuming, of course, that your host OS doesn't muck anything up first.
So are you seriously asserting that \Unicode 2424 should be used in place of \n? Sure, it's pretty and all, but A) it takes a hell of a lot longer to type/specify using a keyboard, and B) common functions should be mapped to common characters. Newline is EXCEEDINGLY common, so it should be very, very fast to specify, not mapped to some obscure graphic buried somewhere in Unicode. (at least 2424 would be pretty easy to remember.)
Your observations of the alternate newline syntaxes were interesting, but I submit that they're probably all inferior to the old \n standby. They all require quite a bit more typing... and newline should be really, really quick to embed.
That aside, the whole thing of 'escaping' characters is a bit silly on some levels... because you run into all this weirdness when you're writing programs that make scripts (that possibly themselves make yet MORE scripts)... debugging how many escapes you need, and where, can take awhile. And escaping an escape character does something else AGAIN... this really does get pretty twisted. The whole IDEA of escaping strings may be a bit broken, a holdover from when we had only 64 or so characters to work with. Data being interpreted as a form of code is a bit dangerous, as we saw with all the formatting string bugs a year or two ago. But, like most dangerous things, it's also powerful.
I wouldn't mind if we were to do it some other way entirely. Unicode might work, but we have only so many keys on the keyboard, and proper Unicode handling is complex. It would require modifications of millions of programs that don't yet support it. Maybe Delphi's idea of an interpreted code fragment, or possibly some internal constants in languages, would be a better idea than using codes to embed escape characters.
I don't see things changing anytime soon, though. Like it or not, we're going to be stuck with \n for a LONG time. And, really... isn't it nicer than \U+2424?
The real question here is 'Gosh, languages don't use all the same syntax to represent mathematical ideas. Isn't there some way we could force them to do so?' And the answer is, succinctly, no.
And for non-visual characters like 'newline'.... what other idea, exactly, did you have? \n is pretty straightforward, once you know how it works. I submit that some random symbol would be worse than what we have now.
The musician Prince tried the glyph substitution trick, if you recall, and it wasn't tremendously successful.
Just as an aside, this is fairly normal for chip companies. They have extremely high margins on their product, but enormous overhead. The fixed costs of building and running fabs are extraordinary... the chip business is probably one of the most capital-intensive (read: expensive to be in) enterprises ever created.
Chip companies make all their money at the margin. Even a very small swing in the total number of chips sold can change their results dramatically. If they blow it and sell 10% fewer chips, the bottom line can drop into serious negative territory. If they hit a 'home run' and sell just 10% more, they make out like bandits.
That's why slumps in PC sales hurt companies like Intel and AMD so badly, and why they can post huge profits very, very quickly after taking enormous losses. High risk, high reward.
I am intrigued by your remarks, and would like to subscribe to your newsletter.
In all seriousness, this sounds apocalyptic, but it matches bureaucratic thinking exactly. If the conflict continues down the current path, I believe this is entirely possible.
If there's a break in the chain anywhere, it would be at the 'great firewall' thing. A firewall like that is likely to be extremely unpopular, and would be very difficult to get through the legislature.
But they might not need it. The UK, at the very least, is demanding that all ISPs archive all traffic forever, so they could just demand logs of 'anyone using US DNS roots' and then fine them.
You UK people that are allowing your government to snoop on you in the name of 'freedom' -- that's just how easily your access to the real, uncensored Internet could be shut off. There'd be ways of getting around it (SSH tunneling, DNS resolvers on different ports, perhaps entirely new name service architectures), but they would likely all be illegal. It would turn into a game of cat and mouse, but probably not one you really want to play. The mice can't WIN in this scenario, they can only avoid losing for some period of time.
Letting the government snoop all of the traffic it wants, anytime, gives it enormous leverage and ability to say what traffic is allowed.
Not for comparable features/quality, you don't. The M2000 has a better display than the SB2's, (512x32 versus 320x32), but is a great deal more expensive, at $400. The wireless SB2 is $250 right now. There are codes floating around at times that will give you another $20 off that. Roku's M1000 is about $200, but its display is inferior(280x16). And note that BOTH the 'high-end' Roku models only support wireless-B mode. If you have a G network, setting it to mixed mode will give you a speed hit right up front. And you're not going to be able to run more than a couple of boxes if you're using lossless audio. (unless, of course, you want to spend a whole lot of money buying more APs.) The SB2, with native G support, would drive roughly five times as many players, which certainly improves your chances of having useful bandwidth left over once your installation is done.
Slimdevices also offers a wired-only version of their player at $179, which is exactly the same as the higher-end model in all respects, less the antenna and wireless circuitry. Roku's cheapest model is $149, but its display is 2 lines of 40-character monochrome. Yuck.
I also note that Roku doesn't mention what DACs they're using. The SB2 uses Burr-Browns, which have a sterling reputation. You may not need them if you're outputting digital to a (good) receiver or prepro, but if you have cheaper gear or want to use headphones, the SB2 is probably better. And keeping your options open never hurts.
I'll give the Soundbridge an edge on appearance, but the hardware appears to be both overpriced and under-specced. The SqueezeBox2 blends very nicely, has a very attractive display(quite a bit better than the M1000's, not as nice as the M2000's), and does native G and painless network bridging. And it has really good DACs. It's a no-compromises product.
I don't, after all, buy audio gear to look cute. The SB2 looks like a quality piece of hardware (which it is), and that's all I need. I'll leave the chrome edging to the Bose crowd.
It's also nice to support the people sponsoring the SlimServer software, which can (as you point out) be used with other hardware than their own. Money invested there benefits everyone.
Slashdot Mirror
The problems are worse with the 2.6.14 kernel, not better... it just took awhile for them to start showing. I'm filing a bug report... hopefully it will help.
Well, perhaps it is indeed finally working... the ACPI messages describe the chipset by name now (VIA KT333), and are much more verbose about exactly what they're doing. I did think of the BIOS angle, and there have been no updates on this board in many, many moons. It was perfectly stable for me under Win2K as a desktop, a very nice board, and it stabilized nicely in noacpi mode. I do not think the board or the BIOS were at fault. I definitely haven't made any BIOS-level changes between then and now, so the increased verbosity leads me to believe that it now understands the chipset and will work. It didn't before, and mysteriously broke without any warning at all.
<rant> It should have, very clearly, told me that it didn't recognize the chipset it was on and that it was GUESSING at the settings. That would have saved me a couple of hundred bucks, because that would have been the first thing I'd have looked at, instead of replacing a functional drive. The total lack of any kind of reasonable error message whatsoever cost me. On top of that, this new changed behavior (suddenly noacpi doesn't work anymore) in a theoretically 'stable' line of kernels is pretty crappy. Freeze the features and go off and play in your own sandbox. When you're ready for testing, I'll happily jump in and start beating up on the RCs, once every 18 months or so.
I don't have time to do that every six weeks as yet more untested, unproven code is jammed down my throat along with the bugfixes I need to the LAST batch of untested, unproven code. I'll happily be QA once in awhile. I don't want to be QA all the damn time.
Right, I did think of that after I posted.... perhaps it is finally fixed. But APIC mode scares me... it's bitten me personally, and I've seen numerous (bad) stories about it from others. I didn't start out particularly worried about it (or anything else in 2.6, for that matter), but I sure ended up that way. And with Linus' reputed habit of doing invisible security fixes, falling back kernels isn't a good idea unless one absolutely must.
Maybe, just maybe, they've nailed it down and it finally works. I'm sure they'll get it eventually. But from past experience, I wouldn't want to bet very much money on any specific release being the likely candidate. They're not letting the old code stabilize. Instead of fixing bugs and having a 2.6 maintainer, they're constantly shoveling new features at us along with the bugfixes. Either we accept them, or the distro maintainers have to work furiously to backport the bug fixes to kernels that are obsolete, being 90 days old.
That's NOT the way to get a stable system. The old way of doing things, with a stable release that lasted longer than two months, worked pretty well. This method, in my not at all humble opinion, doesn't.
One of the core kernel crew, I believe it was Rik Van Riel, said that it was pretty much fine with him if only one 'stable' release in three was actually stable.
Maybe I got lucky, and this is it.
There are two main reasons to run GRUB. The first is because you can build new kernel start lines on the fly. LILO has to be hardcoded with kernel locations on disk. You can change the boot parameters, but you can't start random kernels. GRUB, on the other hand, understands enough of the filesystems on which it lives to allow you to boot arbitrary kernels on the fly.
The second reason (closely related) is that if, for some reason, the kernel files move around on disk (did you just restore from backup?), LILO blows up, and GRUB just works.
Either bootloader can be used safely to remember multiple different kernels for routine experimentation.
The Linux kernel has many features, but it has them at the expense of stability. This new kernel did not drive the network card properly on my server, an Athlon 1900+ on an ASUS K7V333. It complained about stuck interrupts.
To get it to run, I had to remove the 'noacpi' line from the kernel boot parameters. This makes me very nervous, because I ADDED it to fix a problem with the software RAID code on this machine. I got occasional, mysterious "ACPI error" messages in the system log, with no other explanation whatsoever. Then my RAID started failing routinely. One particular drive always failed, so of course I thought it was the drive, and replaced it. The new drive immediately started failing in exactly the same way.
Only by adding in the noacpi line was I able to use the system reliably. Now that noacpi no longer works, I may be backed into a corner... I may end up having to switch to some other server software I can trust. The Linux team's refusal to maintain old code without adding new features, just waving their hands in their air and saying that the distros will make it right, doesn't work for me. I already switched my firewall over to OpenBSD because I was tired of the incessant patching, security hole after security hole. On a CF-based system, that's a pain in the ass to administer. I haven't had to touch OpenBSD since I installed it, months ago.
I like features, but first and foremost I use open source software because it doesn't break. At least, for a long time, it didn't. The 2.6 kernel has directly cost me a couple hundred bucks, has had an absolute horde of problems ever since it shipped, and just failed for me YET AGAIN.
You may be impressed by all the whizbang features, but more and more, Linux is falling into the exact same trap that Microsoft has... shipping features instead of a solid product.
Probably the single best resource on the Net for kernel discussion is Linux Weekly News, www.lwn.net. The main editor, Jon Corbet, is a very rare breed, a lucid writer who more or less understands the internals of the Linux kernel. As far as I can tell, in the entire Linux universe, this consists of a population of exactly one.
LWN has been around a long, long time, and it's one of the best Linux sites on the Net. Don't be put off by the relatively simple site design. The content is second to none.
Most of the really good stuff is on a time delay. If you subscribe, you get access immediately. Otherwise, you have to wait a week or two. Please do subscribe if you like it. It's not very expensive, and it's important to support the really good resources. Linux Weekly News is one of them.
(I'm not affiliated with them, except that I send in money every month.)
I had no trouble at all plugging in two different multi-button Logitech mice to my Mac G4. It recognized most of the buttons without any software at all. The right and middle button, the scrollwheel, and the forward and back thumb keys all worked immediately. I believe only the middle thumb button on the MX1000 failed to register. With some Control Panel changes, it was easy to map Expose functions to whatever buttons I wanted.
I haven't tried anything but Logitech mice, but the Mac seemed fully aware of all the capabilities (except the one button.)
YMMV using other brands.
I was talking about the computer monitor, the 24" widescreen. I think the TVs have them too, but I'm not sure if they have as many.
Generally, the only way to see them is to display a solid white image, and then get very close to the monitor and look either in the middle or at 1/3 and 2/3 of the way down the screen. You're looking for very, very thin horizontal black lines. They're completely invisible in normal viewing... you have to really look to find them.
That's not a defect, it's by design.
A Trinitron tube has thousands of tiny vertical wires to disperse/channel the electron beam. The horizontal wire is necessary to keep the vertical ones from moving. To see it, you generally have to know what you're looking for and explicitly try to find it... it's not at all obvious. That's the price you pay for the superior picture.
The really big 24" monitors have two wires, at 1/3 and 2/3 the way down the screen.
Refresh rate in an LCD spec is really what the receiving circuitry can handle/adapt to. It doesn't change how fast the actual LCD elements update. A CRT is constantly drawing the screen, left to right, top to bottom, X number of times per second. So the refresh rate is very important there.... the faster it goes, the less flicker. An LCD emulates this behavior, by letting the monitor update an internal buffer up to X times a second, where X is the maximum refresh rate it supports.
If I understand the technology correctly, LCDs do an instant update of every pixel on the screen simultaneously every 1/60th of a second. (possibly faster in the newer, sub-16ms LCDs). It just writes out whatever was most recently loaded into the buffer, meaning that if the monitor is running faster than 60hz, frames will get dropped. This could cause image tearing as well, though the monitor could do internal double-buffering to prevent that.
Well, I play on a Dell 2405FPW(16ms = 60fps), and it seems fine to me, though I'm certainly not (anymore) a terribly competitive FPS player. I used to play at 85hz on my CRT, and I'm at 60 now, and I don't really notice a difference. Maybe when I was younger it might have mattered.
I'm really quite impressed with how well this unit scales. Earlier LCD scaling was incredibly horrible. I think it must be actually scaling the images past the native 1920x1200 resolution and then sampling back down. It doesn't have hard edges, it sort of blurs. It's not as good as a CRT, but it's close. You can tell it's not native resolution if you look, but you have to LOOK. It's not instantly apparent.
LCDs have come a long, long way in the last three or four years.
I think that's changed in Unstable, and presumably Testing as well. Right after the current Stable shipped, I had a big hassle with updating keys, and complaints by my systems that packages were unsigned. It wasn't hard to fix, but the systems complained loudly until I did. So I don't think that particular objection applies anymore.
:-)
RedHat and Suse, as you point out, are the best-supported by Oracle... as far as I know, they're the only vendor that anyone really cares about.
Well, from the standpoint of a programmer or an administrator, it's very good indeed at getting to destinations. For the stuff that I do professionally, Windows just doesn't cut it, at least not without adding in a lot of other stuff. Unix is very popular in the sciences too, for similar reasons.
As far as your particular goals go... I haven't done that much with video encoding, but I was under the impression that Linux was pretty good in that area? It's certainly very good at working with music files. For instance, I have all my music stored as CUE/BIN files. When I bought the Squeezebox2 (a great music player, btw), I found that it would natively support CUE/FLAC. So I took about 45 minutes to whip up a script to recurse through my entire directory hierarchy, encode to FLAC, and massage the CUE files to point to the new FLAC files instead of the WAVs. (took several days to actually run, but I just left it going under screen, so I didn't have to fool with it.) I would have had a hard time doing that under Windows.
I don't have personal experience here, but I'd assume that most of the video-encoding programs should work under Linux the same way. You could easily script something, for instance, to encode a raw dump whenever you saved one, even to several different formats if you needed that. That kind of thing is hard to do with a GUI... not impossible, but usually awkward.
I think, in reading over your post, that perhaps you haven't stepped up to the next level yet, which I didn't do until I was forced to use it full time. Linux gives you an awesome array of tools, but it's still mostly up to you to assemble them into what you need. But once you have cobbled together a script to do something, expanding it, or replacing pieces of it, becomes quite easy.
For years, I was poisoned by the Windows Way, which is basically "use other people's applications in the way they intended". Linux doesn't work that way, so much. I think it's when you realize you have an incredible amount of control, and that you can very often build your own custom solution to a problem in a fraction of the time it would take under Windows, that your productivity really starts going up.
I think trying to use Linux the same way you use Windows is a perfectly good first goal, but if you stop there, you'll never exceed your Windows productivity... in fact, you'll probably not even match it. I think that may be where you're stuck. Treat it like Windows and that's all you'll get out of it. Treat it like Unix, and you can do magic.
The single best piece of advice I can give you is to find people who use Linux a lot (and that you like) and hang out with them. An awful, awful lot of Unix is arcane lore, passed on from person to person.... powerful ways of approaching problems that aren't ever mentioned in the documentation. Unless you have a truly extraordinary mind, far better than mine, you'll find learning it on your own to be an uphill battle. It certainly was for me. Linux/Unix is a mindset as much as an OS, and it's much easier to learn it from people who already know it, rather than having to invent it all yourself.
First, you have to realize that I'm pretty geeky... my experience may not translate well to Grandma or Uncle Joe.
My transition was almost accidental. I'd taken on a new job administering a network of Linux servers. I was provided a Windows desktop and several spare machines that I could use for whatever.. the prior administrator had liked to tinker with things. The Windows machine proved to be unreliable, and I was unable to determine if the company had paid for my Windows license at the time, so I just installed Mandrake on a spare box. I'd originally intended it as a secondary machine, but I ended up being happy enough that I never switched back, at least for work. (I still run Windows at home, mostly for gaming.)
After getting past the initial learning curve, I felt more productive because I had instant access to a huge range of powerful utilities. One of them, interestingly, was the humble bash shell. After settling in permanently and learning how to script properly (which I had never actually done before, though I'd been using Linux for years...I'd just not needed the ability sooner), I was able to automate a great many administrative tasks. That would have been much harder with Windows. I would have needed Cygwin, which is essentially Unix anyway. And screen and ssh were incredibly useful as well. I don't mean just the basic command-line ssh, but the remote-command, piping, port redirection, and proxying capabilities. That kind of thing is harder to do in Windows, and you definitely have to pay for it. (unless, of course, you use Cygwin, but it's still not native to the platform in quite the same way. If you're going to use free software anyway, might as well do it right.)
From a desktop perspective, I prefer Evolution to any other email client I've tried. It has the look and feel of Outlook, but is all Unixy underneath, so gluing in other programs is trivial. Adding in spam detection took very little time, for instance, and cost nothing, quite unlike the commercial alternatives. I loved the sorting rules and the ability to transparently support multiple email aliases (so I could be postmaster, webmaster, support, and my 'real' email address, without having to think much about them.) And I prefered Konqueror to any other browser I'd used up to that point. It ran faster, had tab support, and just in general struck me as superior to IE, except when it failed to render something. Fortunately, that wasn't terribly common, and Mozilla was there when Konqueror couldn't handle it. (Firefox wasn't out at the time I was making the transition.) And I absolutely loved the High Performance Liquid theme in KDE.
Multiple workspaces was a big productivity boost once I figured out how to organize it.... web browsing in one screen, email in another, remote jobs in a third (abstracted with the 'screen' utility so I could check up on things from home if I wanted), music player, network monitoring, and various random things (nethack!) in a fourth.
It's been quite awhile, so my memory has dimmed, but I believe but the rough edges were mostly determining how to get the hardware configured. Screen resolutions were a real pain. Getting sound working properly was also hard, and then determining/shopping for the best program to use for the different available functions. (I had quite a bit of experience with server Linux, but desktop Linux was pretty new to me.) A lot of this stuff was hard simply because related settings were spread all over multiple screens... they were organized by how the software was built, rather than by how people thought about the problem. Even now, the interfaces to system configuration stuff tend to be much harder than they should be.
Overall, there just weren't any artificial barriers between me and the system. It was still easy to use, but it was easy without hiding the power underneath. Windows abstracts things but then makes it very hard to get down to brass tacks, past the abstractions. Linux isn't like that. If you want to see ho
If you're still reading this thread, I thought I'd mention that they just announced (I got the mail about 10 minutes ago) the Squeezebox3, which adds native WMA support and looks nicer. But it's back to the old $299 price for the wireless version, $249 wired. (SB2 is $249/$199). Same very, very high-quality components.
The new design is more vertical and cleaner. It still kind of reminds me of a clock radio, but it's nicer-looking than the VHS-tape clock radio style of the SB2.
Tell them to try LiveCDs first, just to tinker. They let you play with Linux with zero commitment. Just be sure to explain that a 'real' install will be a lot faster, because it runs from the hard drive.
When you're ready for a hard drive install, I've been recommending Mandrake/Mandriva for new users for several years now. I started using it in the 8.X series, and after a short readjustment period, it was a total Windows replacement for me. I felt a lot MORE productive on Mandrake than on Windows, once I'd figured it out. It had some rough edges, but overall worked very, very well.
I've used a lot of Linux desktops over the years (Ubuntu, Debian, Redhat up to the 7.X series, Slackware, SLS), and I've always thought Mandrake was the best. (though Ubuntu is pretty nice too... you might want to try both.)
I don't have any experience with Suse, because for a long time you had to pay to get the best install options. The free version was purposely awkward to install, so I never bothered with it. Suse's loss, too... I liked Mandrake and I've sent them, geeze, three or four hundred bucks by now, probably. I just didn't want to pay BEFORE seeing the product. Now that they're more GPL-ish, they may be a very good spot for new users to tinker. I'll download and play with this one and see what's up with it.
For your friends, though, definitely start them on LiveCDs. They're easy to use, cheap to download and burn, and if they aren't impressed, all they have to do is shut down and eject the CD.
True, but also keep in mind that there are things that might have been even better that we still haven't discovered for lack of funding. Research, particularly basic (non goal-oriented) research, pays enormous dividends. Even if it's defense-based, the ROI is so enormous that the discoveries routinely affect everyone. Yes, we get many knock-off products from defense research, but that does not mean that this is the best possible way to allocate research dollars.
If the real goal is the advancement of knowledge and the human condition, then researching how to build things rather than destroy them would probably be a better solution. We'll still get the side effects (hey, this new roofing material is superb for boot soles!), but the original intended effects will be more broadly beneficial.
With the regular full Workstation version (I have no need for Player, but I assume it works the same way), you choose, from a dropdown menu, a USB device that you would like to connect to the virtual machine. VMWare 'unplugs' it from the host OS, and plugs it into the guest OS, until you quit the program or detach the device again.
What I did was to attach my USB hub to the virtual machine, and then plug flash modules in and out. That works fine, so I presume you'd be able to hotplug anything else you wanted. The guest just needs to 'own' the hub.
I think in earlier versions, the mouse focus had something to do with hotplug events, but I *think* they have changed that to the above system.
If you can't attach the hub to the guest, I think you'll have to plug it into the host system first, and then attach it to VMWare. That will simulate a hotplug, and will probably work for most devices.... preuming, of course, that your host OS doesn't muck anything up first.
That's actually not a bad idea. Wonder if someone will pick it up and run with it?
They used a frame to overlay the graphic over a portion of the article. I bet you couldn't even tell which part.
So are you seriously asserting that \Unicode 2424 should be used in place of \n? Sure, it's pretty and all, but A) it takes a hell of a lot longer to type/specify using a keyboard, and B) common functions should be mapped to common characters. Newline is EXCEEDINGLY common, so it should be very, very fast to specify, not mapped to some obscure graphic buried somewhere in Unicode. (at least 2424 would be pretty easy to remember.)
Your observations of the alternate newline syntaxes were interesting, but I submit that they're probably all inferior to the old \n standby. They all require quite a bit more typing... and newline should be really, really quick to embed.
That aside, the whole thing of 'escaping' characters is a bit silly on some levels... because you run into all this weirdness when you're writing programs that make scripts (that possibly themselves make yet MORE scripts)... debugging how many escapes you need, and where, can take awhile. And escaping an escape character does something else AGAIN... this really does get pretty twisted. The whole IDEA of escaping strings may be a bit broken, a holdover from when we had only 64 or so characters to work with. Data being interpreted as a form of code is a bit dangerous, as we saw with all the formatting string bugs a year or two ago. But, like most dangerous things, it's also powerful.
I wouldn't mind if we were to do it some other way entirely. Unicode might work, but we have only so many keys on the keyboard, and proper Unicode handling is complex. It would require modifications of millions of programs that don't yet support it. Maybe Delphi's idea of an interpreted code fragment, or possibly some internal constants in languages, would be a better idea than using codes to embed escape characters.
I don't see things changing anytime soon, though. Like it or not, we're going to be stuck with \n for a LONG time. And, really... isn't it nicer than \U+2424?
The real question here is 'Gosh, languages don't use all the same syntax to represent mathematical ideas. Isn't there some way we could force them to do so?' And the answer is, succinctly, no.
And for non-visual characters like 'newline'.... what other idea, exactly, did you have? \n is pretty straightforward, once you know how it works. I submit that some random symbol would be worse than what we have now.
The musician Prince tried the glyph substitution trick, if you recall, and it wasn't tremendously successful.
Just as an aside, this is fairly normal for chip companies. They have extremely high margins on their product, but enormous overhead. The fixed costs of building and running fabs are extraordinary... the chip business is probably one of the most capital-intensive (read: expensive to be in) enterprises ever created.
Chip companies make all their money at the margin. Even a very small swing in the total number of chips sold can change their results dramatically. If they blow it and sell 10% fewer chips, the bottom line can drop into serious negative territory. If they hit a 'home run' and sell just 10% more, they make out like bandits.
That's why slumps in PC sales hurt companies like Intel and AMD so badly, and why they can post huge profits very, very quickly after taking enormous losses. High risk, high reward.
I am intrigued by your remarks, and would like to subscribe to your newsletter.
In all seriousness, this sounds apocalyptic, but it matches bureaucratic thinking exactly. If the conflict continues down the current path, I believe this is entirely possible.
If there's a break in the chain anywhere, it would be at the 'great firewall' thing. A firewall like that is likely to be extremely unpopular, and would be very difficult to get through the legislature.
But they might not need it. The UK, at the very least, is demanding that all ISPs archive all traffic forever, so they could just demand logs of 'anyone using US DNS roots' and then fine them.
You UK people that are allowing your government to snoop on you in the name of 'freedom' -- that's just how easily your access to the real, uncensored Internet could be shut off. There'd be ways of getting around it (SSH tunneling, DNS resolvers on different ports, perhaps entirely new name service architectures), but they would likely all be illegal. It would turn into a game of cat and mouse, but probably not one you really want to play. The mice can't WIN in this scenario, they can only avoid losing for some period of time.
Letting the government snoop all of the traffic it wants, anytime, gives it enormous leverage and ability to say what traffic is allowed.
Something to think about.
Not for comparable features/quality, you don't. The M2000 has a better display than the SB2's, (512x32 versus 320x32), but is a great deal more expensive, at $400. The wireless SB2 is $250 right now. There are codes floating around at times that will give you another $20 off that. Roku's M1000 is about $200, but its display is inferior(280x16). And note that BOTH the 'high-end' Roku models only support wireless-B mode. If you have a G network, setting it to mixed mode will give you a speed hit right up front. And you're not going to be able to run more than a couple of boxes if you're using lossless audio. (unless, of course, you want to spend a whole lot of money buying more APs.) The SB2, with native G support, would drive roughly five times as many players, which certainly improves your chances of having useful bandwidth left over once your installation is done.
Slimdevices also offers a wired-only version of their player at $179, which is exactly the same as the higher-end model in all respects, less the antenna and wireless circuitry. Roku's cheapest model is $149, but its display is 2 lines of 40-character monochrome. Yuck.
I also note that Roku doesn't mention what DACs they're using. The SB2 uses Burr-Browns, which have a sterling reputation. You may not need them if you're outputting digital to a (good) receiver or prepro, but if you have cheaper gear or want to use headphones, the SB2 is probably better. And keeping your options open never hurts.
I'll give the Soundbridge an edge on appearance, but the hardware appears to be both overpriced and under-specced. The SqueezeBox2 blends very nicely, has a very attractive display(quite a bit better than the M1000's, not as nice as the M2000's), and does native G and painless network bridging. And it has really good DACs. It's a no-compromises product.
I don't, after all, buy audio gear to look cute. The SB2 looks like a quality piece of hardware (which it is), and that's all I need. I'll leave the chrome edging to the Bose crowd.
It's also nice to support the people sponsoring the SlimServer software, which can (as you point out) be used with other hardware than their own. Money invested there benefits everyone.