Ksplice Offers Rebootless Updates For Ubuntu Systems 211
sdasher writes "Ksplice has started offering Ksplice Uptrack for Ubuntu Jaunty, a free service that delivers rebootless versions of all the latest Ubuntu kernel security updates. It's currently available for both the 32 and 64-bit generic kernel, and they plan to add support for the virtual and server kernels by the end of the month, according to their FAQ. This makes Ubuntu the first OS that doesn't need to be rebooted for security updates. (We covered Ksplice's underlying technology when it was first announced a year ago.)"
GPL "terms of service"? (Score:5, Interesting)
They appear to be releasing this licensed as GPL v2, but they have a "terms of service" click-through, according to their screenshot.
That doesn't give me great confidence that they really understand the GPL....
The technology looks pretty cool, though.
Interesting start (Score:3, Interesting)
It's nice to see them running it on Ubuntu 9.04, but if they want to make money they should go after the LTS releases and SLES / RedHat.
Looks cool though.
Re:GPL "terms of service"? (Score:4, Interesting)
Some installers are simply built to force an EULA on the user so programs that use those are tempted to put something like the GPL in there.
For you geeks that don't "need" 100% uptime... (Score:3, Interesting)
Re:Great! (Score:3, Interesting)
Re:load of wank (Score:3, Interesting)
Actually, Ksplice provides live patches. The ones Uptrack distributes are all to the kernel, and obviously not restarting the system requires not restarting the kernel.
The Ksplice technology [ksplice.com] itself is free software, and can be ported to userspace (but that hasn't been implemented yet by the Ksplice people). But if your network service is an NFS server or something, or you're fixing a security bug in the kernel, then Ksplice can apply it to a running system without affecting existing sessions / connections.
Re:Difference between Linux and Windows (Score:3, Interesting)
> Windows actually can replace a DLL that is in use by renaming the original then copying the new file into place. However, the Windows world prefers not to do this. Why?
Linux solves this with links. To pick a random example:
lrwxrwxrwx 1 root root 17 2009-06-21 19:04 /usr/lib/libqt-mt.so.3 -> libqt-mt.so.3.3.7 /usr/lib/libqt-mt.so.3.3 -> libqt-mt.so.3.3.7 /usr/lib/libqt-mt.so.3.3.7
lrwxrwxrwx 1 root root 17 2009-06-21 19:04
-rw-r--r-- 1 root root 7534253 2008-03-02 12:04
I'm showing here an output of ls. Say a program open libqt-mt.so.3. It gets 3.3.7. Now I install 3.3.8 while my programs are still running.
lrwxrwxrwx 1 root root 17 2009-06-21 19:04 /usr/lib/libqt-mt.so.3 -> libqt-mt.so.3.3.8 /usr/lib/libqt-mt.so.3.3 -> libqt-mt.so.3.3.8 /usr/lib/libqt-mt.so.3.3.8 /usr/lib/libqt-mt.so.3.3.7
lrwxrwxrwx 1 root root 17 2009-06-21 19:04
-rw-r--r-- 1 root root 7541660 2008-05-02 15:03
-rw-r--r-- 1 root root 7534253 2008-03-02 12:04
So when I install a package, all the new libraries get installed (and their dependencies) and after they are all installed, the symlinks get updated. If a program wants specifically 3.3.7 and is still using it, they can still have that. If they already have that library open, then it stays open. If a new program requests libqt-mt.so.3 then they get the new one.
The interesting thing in linux is that I can now delete libqt-mt.so.3.3.7. If there are any programs that have it open still, the OS will keep the file around. So only when the program quits will the file be really deleted.
For the other problems like:
> When you write code that communicates between processes, you generally expect that the same version of the code will be running in each process
Linux can never make that assumption in the first place, since you other process might not even be on the same machine (exported program) or it might be running in a scratchbox (a completely different environment) etc.
Re:Great! (Score:3, Interesting)
It's a cool piece of kit, but I wouldn't use this in a production environment.
If you are relying on one server to maintain 100% uptime in a high availability (which most production environments are) situation, you are probably doing it wrong.
It's my opinion that in a ha environment, you _should_ be able to reboot a box with no loss of uptime to the system as a whole.
I would even go as far as recommending a reboot every 3 months or so to test your clustering/failover setup (because I think a lot of people set this up once, then never look at it again until they need it 2 years later). Additionally stuff like kernel updates might BREAK the way in which your box boots up. Much better to discover that right after the update than a year down the road when the box goes down because of a bad PSU. A test of your boxes ability to automatically go from power off to full availability is probably a good thing[tm]
Re:Great! (Score:3, Interesting)
Well, OK. Let's start with X.
X really is a pain in the ass to deal with. Ever tried to get dual monitors working? OK, ever tried to get dual monitors with differing resolutions working? My standard work configuration when at my desk is two widescreen monitors, one 1280x800 (my laptop panel--I don't use a desktop right now) and a 1440x900 LCD monitor, oriented vertically (great for reading or code listings, I can't recommend that enough!). I spent far too much time trying to make this system work under Linux. All indications were that it's just not possible. Which is a shame, because I find it to be the best way for me to work.
(X is also a huge problem for numerous other reasons--a friend of mine worked for nVidia and related horror stories very similar to Linux Hater's blog on the topic. Mesa, as an open-source OpenGL solution, is preposterous and while there might someday actually be accelerated 3D drivers on a level of performance with closed-source drivers, I really wouldn't bet on it. Don't give me any bullshit about patents or "they have people working just on this"--I know and I do not care. It's so unfortunate that they have a problem. Emphasis on "they" have a problem. I'm an end user. I don't give a damn about their problems, I give a damn about their solutions.
And whoever thinks DRI is still relevant today needs their fucking head examined. You can't run Compiz and a 3D-accelerated application at the same time under DRI, but it works just fine under nVidia, because nVidia's "drivers" in reality rip out most of the lower third of the X stack in order to bypass some of the X braindead failures. The DRI architecture cannot be fixed, either, which makes this even more fun. It's not like any of this is novel, though: SGI had a workable rendering system in IRIX in the late 90's. X? Still waiting!)
Moving upward: while GNOME has made some pretty significant strides over the last two years, it's still just plain not very good. It's clunky--although much of this comes from GTK+ being nearly impossible to theme in an attractive manner, and the widget set's propensity for obnoxious amounts of padding, compare MonoDevelop and Visual Studio regardless of the theme on the Linux machine using MD and you'll see what I mean. The HCI for GNOME is bugfuck retarded (are you sure? [No] [Yes]). The applications, while often functional, lack polish and the sort of pleasantness to use that you find on OS X or even Windows. (The GIMP is a prime example. Nice backend. Horrible, horrible frontend, and a community of developers who are incapable of understanding that programmers don't understand users.)
KDE used to be my preferred desktop. It was fairly good-looking (although, and I hate to say it, Vista makes 3.5.x look really crap and 4.x not much better), and was relatively pleasant to use. It was obvious that people actually put some thought into HCI, even if their conclusions were not always right. Then KDE4 happened, and made me start wishing a bus to hit Aaron Seigo. 4.x is a departure of what KDE is as far as I'm concerned, and the cavalier attitude of their developers toward their users will prevent me from going back to it.
The suggestion of WINE for anything is preposterous. While WINE is quite an impressive project (and has delived good results), it simply should not be needed. If you're pimping Linux as an alternative to Windows, you'd better have all the applications people want (and that includes games as well as Photoshop--I'd say Office, but I won't be that unreasonable).
Bringing us to games, I would argue that the lack of an organized, coherent framework for media is hurting Linux as much as anything. Where's the DirectX equivalent? Where's the one-stop-shop-for-all-your-needs? Game developers aren't going to fuck around trying to find the best solutions for a project. On Windows, it's pretty much DirectX or bust because DirectX is good enough and convenient. Convenience cannot be underrated as a factor of importance. W
Re:Great! (Score:3, Interesting)
KDE 4 really isn't as bad as you're making it out to be. There are some changes I don't necessarily agree with, but all things considered I'm pleased with the direction it's taking and look forward to when the release a feature-complete version (4.2 is getting close, though!).
It is as bad, and I'm not going near it while the current bunch of idiots is running the show.
Your last sentence is kind of comical. Have you ever _read_ the Gnome mailing lists? If you want condescending, disdainful discourse, that's a great place to start.
The GNOME mailing lists are immaterial as long as they treat their users with respect in normal discourse. I don't care what assholes they are to each other. Meanwhile, KDE insists that "they don't need users." I have contributed to KDE applications in the past, and there are two 3.5 themes on KDELook that I have authored. Fuck 'em. They don't want users, they don't want me, because I'm a user first and a contributor second, and their hedging bullshit regarding "well, contributors aren't users" is unacceptable.