Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

diegocg writes "Linux 2.6.34 has been released. This version adds two new filesystem, the distributed filesystem Ceph and LogFS, a filesystem for flash devices. Other features are a driver for almost-native KVM network performance, the VMware balloon driver, the 'kprobes jump' optimization for dynamic probes, new perf features (the 'perf lock' tool, cross-platform analysis support), several Btrfs improvements, RCU lockdep, Generalized TTL Security Mechanism (RFC 5082) and private VLAN proxy arp (RFC 3069) support, asynchronous suspend/resume, several new drivers and many other small improvements. See the full changelog here."

Well, it's a kdawson post - he's notorious for posting Slashvertisements for the latest brand of rip off Snake Oil. I mean, "Linux", come on, what's that supposed to be? Some shoddy knock off of BSD/MacOS Unix? I bet it's just the periscope of a Microsoft patent submarine.

KVM is fantastic virtualization technology, yet Xen gets all the hype these days. Why? Paravirtualization is pretty cool stuff, but seriously, what CPU's are made without some type of hardware-assisted virtualization support?

I'm sure you are disappointed that your 200Mhz Pentium Pro doesn't support vt-x, but the rest of the world owns (or will soon purchase) processors that do. To see what I mean, just go to newegg.com. 63 out of the 76 (83%) desktop-class [newegg.com] processors they sell have virtualization technology built in. 78 out of the 80 (98%) of the server-class [newegg.com] (ones that really matter) processors they sell support it.

And, if you still don't believe me, check out this page [wikipedia.org] on Wikipedia for a list of the Intel processors that support VT-X. Among the crapload of processors listed, you'll notice that 100% of their newest, i3, i5 and i7 processors have virtualization support.

If you want an inexpensive chip, you should carefully check Intel's support for virtualization - by example, some of the E7400 and E7500 had it, some didn't. Same for E5400 and E5300 (some have it, some don't).

I get the impression that the issue with the parent is regarding the motherboard, not the processor. HP have a habit of having their own bespoke boards in their desktop machines, more often than not with custom BIOS. Unless you have an HP computer (or Dell, Acer, $vendor machine) your situation will more than likely differ to theirs.

We have a bunch of HPs in the office that I thought had this problem too. However, it turns out HP hides the VT-X enable flag under the Security Options in the BIOS (I can only imagine how that makes any sense, but whatever), at least on their desktop machines. Could be worth a look.

You put your virtualization on the new machines not on the hand-me-down stuff, silly. Your old machines weren't speced for them. You need to run the thing on a box that can take a crap-ton of RAM, has really fast I/O, and depending on the load, has the ability to take a NIC per VM.

"Virtualization is supposed to CUT costs, not incur new hardware costs"

It does cut costs... it cuts hardware costs by allowing you to buy fewer servers. Instead of buying new servers for DNS, LDAP, Web, and Email, you can buy o

KVM is fantastic virtualization technology, yet Xen gets all the hype these days. Why? Paravirtualization is pretty cool stuff, but seriously, what CPU's are made without some type of hardware-assisted virtualization support?

Xen doesn't get all the hype. From what I've seen everyone is ditching xen and redhat is leading the way. Not that I mean to imply that xen deserves to get ditched, it's great too.

I think Redhat's dropping of Xen for KVM is as much politics as anything else. In the eyes of business, Xen = Citrix, and if going for Xen, why not go for Citrix?

Personally, I'm very pleased with Xen except for the qemu IO performance. Setting the host's block device schedulers to noop (for linux guests) or deadline (for Windows guests) helps, but high host IO load still makes it very hard to do advertised features like instant failover using an NFS-hosted container.

Personally, I'm very pleased with Xen except for the qemu IO performance. Setting the host's block device schedulers to noop (for linux guests) or deadline (for Windows guests) helps, but high host IO load still makes it very hard to do advertised features like instant failover using an NFS-hosted container.

The solution to this would be to use PV drivers for HVM DomUs. This effectively closes the gap in performance between Paravirtualized DomUs and Fully Virtualized DomUs. Commercial XenServer provides them, and people routinely Build them. They are a bit of a pain to install on vanilla Xen DomUs, for they are not signed, and require a boot argument to be added to windows (/GPLPV) but they work as advertised.

KVM is fantastic virtualization technology, yet Xen gets all the hype these days. Why? Paravirtualization is pretty cool stuff, but seriously, what CPU's are made without some type of hardware-assisted virtualization support?

Er, it's KVM that gets all the hype these days because it's still got some novelty. Xen just has the users, because it's simply more mature.

full featured management tools. kvm is woefully behind the curve. until you make it approachable by administrators used to the xen management tools and vmware virtual infrastructure client you won't see it catch on like other hypervisors have. sad but true.

Well... in part because the open source world had embraced and promoted it for a long time. Corporations buying up open source projects and using them as a base platform for their commercial products is a problem. Or is it not? I'm not sure I understood exactly what happened with Xen and open source.

If "better" means once-working wifi chipset becomes grossly unstable, previous drivers are considered "legacy" hence will not compile on kernels later that 2.6.29 and current drivers are as stable as a "one-legged man playing football".

A few years later and 2.6.34 is released - is it working yet?

Considering the RT2500 chipset is present many wifi products the current state of "stability" is woefully inadequate.

(and don't get me started on f***ed up i845 drivers for xorg! - worked fine under previous kernels & xorg an update later by both - graphics performance royally screwed and many crashes)

Here's how the dismal state of support for that chipset was explained to me.The answer is probably that mine has worked for years and yours hasn't. The really annoying thing is a lot of slightly different things have come out under that name and even under MS Windows if you don't use the driver that came with it you are stuffed - a driver for another undocumented variant won't help.

The problem is that the RT2500 chipset is proprietary, closed-source that's "maintained" by a Taiwanese manufacturer who doesn't care about his users at all and only wants to sell cheap hardware and as much of it as possible.

Why would you get quality, polished drivers that are updated to support newer paradigms in newer kernels if the manufacturer isn't cooperating?

I think it's magic that these drivers work at all.

Next time, buy better kit with a reputable mfr that cares about linux support.

What, you think the driver model, network stack, etc, in Linux is 100% static and will never, ever change?

The only reason you think it's "retarded" is because Microsoft likes these big splash releases every five years, while Linux is constantly evolving, and that means if the driver model changes, it could very well be between minor revision numbers (which aren't actually minor).

Let me clear it up for you. "Open source" means "If you come bitching and moaning to me that I haven't freely given you enough of my time already, while being too Goddamn lazy to make any contributions of your own, then I will mock you back into the Stone Age."

Let me clear it up for you. "Open source" means "If you come bitching and moaning to me that I haven't freely given you enough of my time already, while being too Goddamn lazy to make any contributions of your own, then I will mock you back into the Stone Age."

So the original post was someone whining to you personally about linux drivers? The guy asked a general question about a driver with some odd history. Either respond like a normal human being or shut the hell up.

Yeah, much like your attitude and you live-up to the narky-sterotypical "open source" kid who put people (and businesses) off Linux altogether.

I would love to fix the source myself but two things hold me back:(1) I just do not know enough about wifi & various chipsets to do something about it(2) Unfortunately, I do not have an infinite amount of time to dedicate to the rt2500 problems (I have other obligations in "meat" space - e.g. partner, kids and full-time job)

The problem is that the RT2500 chipset is proprietary, closed-source that's "maintained" by a Taiwanese manufacturer who doesn't care about his users at all and only wants to sell cheap hardware and as much of it as possible.

Well, actually, Ralink has for a long time been providing documentation to open source developers writing drivers for their devices, without requiring an NDA.

Except they did work, and worked better, in the last version. The kernel maintainers swapped out the working version for a flakey version, and now have made enough changes that the working version won't work even if you compile it in manually.

Did it occur to you to actually read the post you were replying to? This was in all there, not behind a link or anything.

Well, those driver developers are obviously doing a bang-up job is the quality of the driver goes down over time. Kudos, anonymous heroes! Continue to make our software worse! Soon you will have banished the scourge of usable, stable software forever!

That's the other point... they're not anonymous. the manufacturer keeps the specs closed, the chip is undocumented... you rely on the manufacturer's software engineers to write your drivers.. and the manufacturer doesn't care about new kernel versions. they made it work once with the 'current' thing when the chip came out - from then you're on your own.

With releases like these, it's no wonder M$ is getting worried. Been running this kernel a while now on our production servers (even from before it it was tagged release, I like running bleeding edge in order to get the most performance from my company's hardware investment) and save from a few data corruptions issues, it's been rock stable! I have to play with the new KVM support later on one of the servers with the least amount of customers on it (couple of hundreds), looks nice!

Sadly... it looks like my company is looking at going with Windoze for a few important servers because of a few outtages. I know it was because of faulty hardware, because I had just compiled a custom kernel for those servers with just the right flags needed (I want to get the most performance!) but this must have triggered a hardware bug because the kernel worked fine on my work laptop. Sigh...

It looks like my company is looking at going with Windoze for a few important servers because of a few outtages. I know it was because of faulty hardware, because I had just compiled a custom kernel for those servers with just the right flags needed (I want to get the most performance!) but this must have triggered a hardware bug because the kernel worked fine on my work laptop...

Because regardless of what the grandparent said, the above post is insightful. It's also interesting to those who know nothing of Linux but do know of Windows servers falling over because of a mandatory patch, for example. For essential systems, a working stable configuration does indeed make more sense than a cutting edge potentially buggy one.

I hate to trot out Ubuntu as an example, but why do you think they have Long Term Support releases? High availability production servers are not expected to run Ubuntu Server 9.10; It has a lot of patches which may break features which worked in previous versions (just look at the list of dependencies removed when you upgrade). I would expect a significant number of those servers to be running 8.04 LTS, and to potentially upgrade to 10.04.1 when it becomes available (the LTS version of LL still being relatively new and untested).

Because I've heard the exact same thing from people who actually believe it and have done it at their job. It is a comment made by a young, inexperienced person (I can't call them an administrator) who doesn't have the experience to understand the problems with doing this.

Because I've heard the exact same thing from people who actually believe it and have done it at their job. It is a comment made by a young, inexperienced person (I can't call them an administrator) who doesn't have the experience to understand the problems with doing this.

What, can't be. According to slashdot all Linux administrators are born as black belt Linux experts and Windows administrators are all people that got lucky bumbling through their MSCE exam. Usually in comparison where five incompetent Windows administrators could be replaced with one competent Linux administrator, even though you could probably replace five incompetents with one competent one in general.

What, can't be. According to slashdot all Linux administrators are born as black belt Linux experts and Windows administrators are all people that got lucky bumbling through their MSCE exam.

Noone is born a black belt at anything. You have to work at it. There are inexperienced Linux admins just like there are inexperienced windows admins. The ones who can't or don't want to learn end up on windows eventually.

The ones who can't or don't want to learn end up on windows eventually.

That's the dumbest fucking thing I have ever read in my life.

You're seriously delusional if you think that Windows servers are inferior to Linux servers in any way. (Well, "any" way is an overstatement, but any practical way.) If you're doing communication, Exchange is great. If you're doing filesharing/single sign-on, Active Directory is also great. IIS is as good, or better, than Apache at all benchmarks, and has more features. Decent support for technologies like OLAP pretty much only exist on Windows at the moment.

Nobody's going to argue that Windows is cheaper than Linux. But arguing that it's worse, that's harder to make-- unless of course you know fuck-all about Windows and just repeat FUD on Slashdot all day.

You're seriously delusional if you think that Windows servers are inferior to Linux servers in any way. (Well, "any" way is an overstatement, but any practical way.)

You're seriously delusional if you think that Windows servers are as good as Linux servers in every practical way. Linux has advantages beyond cost. For some large organizations, like Google, being able to tinker with the software is essential. For other organizations, some particular feature of Linux might be essential: like DRDB, or support for some application, or good software RAID (much better than Windows from what I've heard), or (soon) btrfs, or performance on their particular workload.

Why are all the replies to this comment seeming to take it seriously?:-|

Because (a) it is Monday morning, and (b) Sturgeon's law applies to/. posters too.And, unfortunately, (c) there are idiots like that out there. But they generally don't change their posting prefs to AC when bragging about their latest folly...

I used to compile kernels, but stopped. There is no way that I, as a single administrator, can perform all the necessary testing to assure that there aren't any kernel problems. So now I don't, but now I get 100% uptime instead. I prefer the uptime to the performance.

Yeah... that's not going to happen. Not only am I good at what I do (seriously, how many system administrators even take their time to compile custom kernels nowadays for maximum performance?), but a very close relative is also the CEO. I bet people here even use us for their hosting:)

There is a massive amount of difference between being able to compile a custom kernel and being in the kind of situation where it's the right thing to do. 'Good at what you do' doesn't mean technically brilliant, it means doing the right thing at the right time.

Keeping your job because you are related to the CEO is the kind of nepotism that kills otherwise good companies.

For the record, obviously I was testing the kernel in a virtual machine on my laptop, using the same version of the distribution we use (in-house, built by me, but originally based on a now ancient version of Red hat).

That's sick, ugly, and wrong. What's worse is you actually think you are doing the right thing.

Stop messing about and replace all the custom stuff with standard stuff before you drag your company to its knees or drive it into the arms of Microsoft.

Either a customer's data is on a server, or it is not. If that machine fails, it doesn't matter if we are running Linux or Windoze or whatever, you still have to startup a spare machine and restore from backups. I just know that if we were running Windoze, we (I) would have to restore failing machines far more often than now, that's all.

Troll or not, you can have redundant filesystem storage (eg: a redundant pair of high-end SAN devices) where the failure of any one component or entire device will not cause any downtime. You're right though... it doesn't matter if you're running Lunix or Windows as your apps will keep on ticking.

> Some laptops have two GPUs, a low-power and inefficient GPU and a high-power and powerful GPU. Users should be able to switch to one or another at runtime. In this version, Linux adds support for this feature. You need to restart X, though.

How do you restart X without affecting all your GUI apps? If you can't restart X without bringing down your GUI apps, I don't see the point for the target audience.

For some people, "only having to restart X" will only save a bit of time over rebooting the whole laptop, reconfiguring bios etc.

How do you restart X without affecting all your GUI apps? If you can't restart X without bringing down your GUI apps, I don't see the point for the target audience.

If you are using something like Gnome or KDE, it can probably save your GUI session. Individual applications will have to deal with their contents, but many of them already do that. At least Firefox and Openoffice can restore their sessions after being terminated.

If you are using something like Gnome or KDE, it can probably save your GUI session. Individual applications will have to deal with their contents, but many of them already do that. At least Firefox and Openoffice can restore their sessions after being terminated.

In KDE, System Settings -> Advanced -> Session Manager -> On Login, Restore Manually Saved Session. After that, you can save your session state from the logout menu or, alternatively, using a shellscript that loops every 30s or so and

When I last used KDE years ago, that didn't work so well. For instance, my ssh connections weren't restored. And even for KDE apps the session saving thing didn't save everything.You may ask "why should SSH connections be restored?" and I'll reply: why should my apps and connections go down in the first place just because X goes down?

Heck even in windows when I kill "explorer.exe" my apps still keep running. I know it's not the same thing, but who cares when all the fanatics keep saying Linux is so stable,

If you can't restart X without bringing down your GUI apps, I don't see the point for the target audience.

For some people, "only having to restart X" will only save a bit of time over rebooting the whole laptop, reconfiguring bios etc.

Not all laptops have a BIOS configuration that allows you to choose the GPU (ASUS UL series for instance). On mine, I had to change the SATA operation mode to have the second GPU work, but this in turn meant a severe performance degradation on my SSD. Without that (deficient) improvisation, I would not have been able to use the second GPU at all!

Besides, logging out of your desktop and then logging in again is surely better than what you suggest?

Good question, but wrong project. The kernel is only responsible for initializing, suspending, resuming and lately modesetting of the hardware and it seems that is possible now. There probably needs to be some userspace code to pull information from one GPU and load it into the other but that's for the xorg server to do. They're probably working on it but it won't be in a Linux (the kernel) release announcement.

The kernel is only responsible for initializing, suspending, resuming and lately modesetting of the hardware and it seems that is possible now.

Plus managing GPU memory allocation. But yes, this is probably something to be added to XRandR, or some other protocol extension. (What would happen to normal, non-X virtual consoles, though? This might require some more stuff in the kernel.)

I'm not saying this is the solution, nor how it should be done, but you could conceivably run a "remote" X-Windows session on a virtual buffer on the laptop - connecting to it with another X-Windows client on the same machine - and then, when you "switch" GPU's, the restart of X-Windows will only affect the "client" viewing the real X-session but be transparent to the user because they'll reconnect to their original session.

It's not a huge stretch of the imagination that the virtual buffer can pass off nece

I agree that's not as useful as it could be, if it was able to do it on the fly easily.

But it could theoretically (I've never tried it) be done using Xmove [wikipedia.org], which "allows the movement of X Window System applications between different displays and the persistence of X applications across X server restarts".

xmove lets the client disconnect from its current X server, and connect to a new one, at any time. The transition is completely transparent to the client. xmove works by acting as a proxy between the clien

I put an openSUSE Build Service version of the.34RC kernel on my new desktop because it fully supported the new Core i5 I'd just installed. Down-side was that there weren't any pre-built nVidia drivers because it wasn't a final kernel yet. Hopefully nVidia will start building the drivers in their repo so that I can move to a repo for my drivers:)

that this kernel already got device IDs for next years Intel hardware. This is something completely new, since Intel so far had a much more closed policy and wouldn't have told device IDs prior to the chipset release.

Now there is a really good chance that driver code will make it into the distribution kernels until the new hardware will be released for mass production. So the chances that brand new hardware will work without any flaws in 2011 are higher than ever before.

Thanks to Intel for this change in their policy. This was a small step for Intel (since everybody "knows" that they will release new chips every year) but a giant leap for providing Linux hardware compatibility right "out-of-the-box".

I'm always amused by at least one strange juxtaposition of the big-serious-enterprise-server stuff that the corporate devs are most interested in and the oddball hobby projects that can get included as well, so long as they follow the kernel process.

In this case, I think it was all the "multi-petabyte scaleable filesystem, esoteric btrfs improvements, kernel virtualization networking stuff, gamecon: add rumble support for N64 pads" that did it.

I'm not sure exactly. The trend for modern oddball devices seems to be doing them in userspace with a libUSB driver. That isn't really a huge issue with game controllers, though, because virtually all of the modern ones are either USB HID or bluetooth HID, possibly with funny connectors(or, in the case of the Xbox360, some proprietary wireless protocol; but the PC dongle is, I believe, USB HID). For such modern devices, Linux does effectively have abstraction layers, either USB HID, or libUSB + userspace co

That went into evdev, I guess, which is an abstraction layer for all input devices. Most probably just a 0 changed to 1 in some device ID table to tell evdev to relay rumble events to the pad (which might not be the default to, e.g., prevent dumb pads from locking up). Just a guess, though.

Native support for ATA discard (better known as TRIM in the Windows world) appeared in 2.6.27, unless I'm mistaken.Support for individual file systems depends on how quickly the FS devs have been able to add their part, but some distros have had working discard with their default file systems for a while now. At far lower kernel versions than 2.6.34:-)