Slashdot Mirror
A "Never Reboot" Service For Linux
An anonymous reader writes "Ksplice, the company based on the MIT Ksplice project, is now offering its 'never reboot' service for Red Hat, Debian, and other Linux distros. You subscribe and get real-time kernel security updates that apply in-memory instead of rebooting. Last summer we discussed the free service for Ubuntu. Cool tech, but will people really pay $4 a month for this?"
How long till they get sued by Microsoft?
http://www.google.com/patents?id=cVyWAAAAEBAJ&dq=hotpatching
..an using some Microkernel OS in which something like this would come as a well-controlled feature, we are using a monolithic kernel and self-modifying code?
Stating the obvious, yes, they are.
But third-party companies are under no obligation to offer their products and/or services for free, and this is a service of a third-party company (Ksplice).
If there is a demand for this service, plus an unwillingness to pay Ksplice for it, it's entirely possible (and likely) that someone will come along and offer an open source equivalent. But until the itch is scratched, Ksplice is perfectly within the right to offer the service at a cost.
Immortality baby! Immortality!
UNIX? They're not even circumcised! Savages!
Maybe if it was almost 497.1 days:)
I do tech support at a school. The moment that something goes offline (like our mail server), we start getting calls telling us that things are messed up.
Before anyone asks: Yes, we try our best to only reboot after-hours, and yes, we tell everyone when a service will be down.
Earn a % of cash back from Newegg, Tiger Direct, Walmart.com, and more: http://www.mrrebates.com?refid=458505
Those who do not perform scheduled reboots of their servers do not know whether their servers will come back up properly after unscheduled reboots. How often have you seen someone add a service to a machine which becomes a critical part of your infrastructure then they forget to add it into the RC system?
You have to save all your work and can't use your computer for 1-3 minutes as your computer stops/boots up again. And you'll probably have to login again, so you'll need to remember and type in your user name and password. And then relaunch all your applications.
Sleep your way to a whiter smile...date a dentist!
Color me stupid but wouldn't any application in which you'd rather not be rebooting (i.e. Router, firewall, file server, etc...) be the exact same application in which you'd NEVER want some 3rd party having access to your kernel? I mean, if a large percent of distros were using this I can just imagine it would be the A#1 target for every malicious coder in the world.
But couldn't this still have the potential to pork your system and force a reboot? Wonder what their policy is on that...
In critical services, 100% uptime is essential. Imagine a server used in air traffic control...
Would someone smarter than me please explain what is so evil about rebooting now and then?
Some organizations who have operational requirements to provide a service continuously. For them there is no acceptable downtime. Having said that I think their safety managers would have a few things to say about software which auto updates kernels on the fly, but that is a different issue. Their preference would be to never update their systems.
http://michaelsmith.id.au
Not expensive if the technology works. My time is more valuable and down servers cost money. The cost is paltry in comparison.
You run a server of any kind. In the old days of novell, we had severs with 6 year uptimes. Not possible today simply from patches, not crashes.
This service has the potential to get us closer to that ever distant 100% uptime. It could definately stack another 9 on 99.999
The occasional reboot, under controlled circumstances, is an excellent test of what will happen in an emergency situation. Mainly, it answers the question of whether the server and required services actually will all come back up by themselves.
Aren't most of the air traffic control servers still using hardware with tubes? I wouldn't be surprised if they haven't updated a kernel in the last 30 years.
We hope your rules and wisdom choke you / Now we are one in everlasting peace
I've said it before, and I'll say it again:
Just because it's free software, doesn't mean that it's afraid of money.
Kid-proof tablet..
Anyone else notice they do not support windows, but the Windows Update dialog is the most prominent in the background image?
99% of people I've seen bragging about long up-times tend to have perfectly patched and up-to-date OS installations on disk, and a dozen vulnerabilities still loaded into memory. And I'm not talking just about the OS kernel.
If you don't know exactly what an update touches, just reboot.
Because I can’t imagine a easier way to obtain an instant-botnet, than to “spice” such a patch. ;)
By the way: Who came up with remote updates? Why not just compile the kernel locally, like normal people do, and then use a special patching tool?
Any sufficiently advanced intelligence is indistinguishable from stupidity.
One would hope that there would be redundancy in such a situation...
"FREE" as in "you are free to obtain the software and its source and do with them what you wish" unlike non-free software that has restrictions on its use and no access to the source code.
"Cool tech, but will people really pay $4 a month for this?"
Depends. If it's your laptop, I suspect the answer is no. If it's your server farm, I suspect the answer is yes.
As an aside: Novell used to run contests to see who had the server with the greatest uptime since its last boot. Best one I ever saw was the Netware server that ran so long that everyone forgot where it was and it was accidentally walled-up inside a closet. Wouldn't it be great if the Linux community could run this type of contest? :)
Regards;
Would someone smarter than me please explain what is so evil about rebooting now and then?
Downtime just KILLS a system's availability requirement.
Having a smoking section in a public restaurant is like having a peeing section in a public swimming pool.
Yeah but how do you make your user interface redundant and load balancing? It is the most important part of the system.
http://michaelsmith.id.au
At an individual computer level it's not so bad, but in an enterprise it can be troubling.
A couple of examples: a zero-day exploit of Microsoft Windows (surely this would never happen) requires a patch be applied and the computers rebooted for thousands of users. Even assuming that the reboot can be enforced with 100% reliability (seldom to never), the 1-3 minutes will impact productivity for at least some users. Sure, desktops can be rebooted at night, but laptop users that take their machines with them and never have them powered up unless they are using them will be impacted. Imagine a company with an average productivity value of $10/hr, $20/hr, or $30/hr. Imagine this company has 100 laptop users or 1,000 or 10,000. Multiplication makes that 1-3 minutes each expensive.
A different scenario involving servers where services must be available: say web servers that require database servers and both require directory servers. There may be several of each of these for load balancing or fault tolerance, possibly clusters, and real world examples may be far more complex. Reboots must be coordinated based on which nodes of which clusters can be taken down without impacting service. Often, additional commands must be added to gracefully transfer service, notify a load balancer device, possibly tell a monitoring server that its in scheduled maintenance mode and not to send a bunch of emails to the support team because the server is down. Ideally one web server and one database server and one directory server go down and all come back up, followed by another set, etc, and cluster master roles are reallocated correctly, etc.
Obviously there are ways to script, automate, plan, and mitigate all of this, but if it didn't have to reboot in the first place... that would be nice, huh?
It depends on what your system is doing. If you're an end user running desktop apps, mostly it's just a pain in the ass. If you're maintaining a server that does something that has to be available all the time, the results range from expensive to disastrous. If the server in question handles credit card transactions for a bank, downtime costs the bank money -- they profit from transaction fees -- and it also costs vendors that use the bank's services. If the server handles air traffic control, the operation of a nuclear power plant, or life support for patients in a hospital, downtime can cost lives. It all depends on what the machine is responsible for.
While it's probably not all that directly important to you (or, for that matter, for me, since I am blessedly free of sysadmin duties at the moment), it does affect all of us indirectly, since the perceived reliability of Linux has a marked effect on the resources any number of companies and institutions are willing to pour into it, some of which is going to be source code that is then shared by everyone.
But the short answer is it doesn't matter much in 99.9% of cases. For the remaining 0.1%, rebooting can be a very big deal.
Proud member of the Weirdo-American community.
No, they're not.
You see, one radar installation can feed multiple stations, and it's quite common for modern ATCOs to sit at a screen that has feeds from multiple radar sources.
In fact, in the UK we recently pulled out all the old PDPs out of West Drayton and transferred radar control down to Swanwick running on relatively new equipment. I believe this was not done by "clearing the skies" first, they just handed over control to the new guys.
I've heard things about US traffic control being old and antiquated, but I'd hazard a guess to say the vast majority aren't using vacuum tubes, CRTs or the like. I imagine many have converted to electronic paper strip bays for the flight plans too.
Yes, but if it's truly a critical service you're talking about redundancy and probably a set up where you can afford to take down one server at a time every few months to reboot/clear the gunk. If you've only got one machine, you're already fucked. You just haven't noticed yet.
For a server running, say, a big web site, or a database, or something else where time is money, and there are a lot of zeros involved, uptime is crucial. When a stock broker's trading floor system goes down, the loss is measured in millions of dollars per second (disclaimer, my brother used to work for a Wall Street firm, his wife used to work for another, and I have two close friends who still work at a third; my estimate is based on things they have told me). Downtime is just not acceptable under some circumstances.
Sure, if my GoDaddy-hosted web site goes off the air for a minute or two while the virtual server gets rekicked, I can't really complain. I end up rebooting my laptop once or twice per week. My desktop gets rebooted maybe twice per year for some hardware update. Users of single-user machines are generally far more tolerant of reboots since, nominally, they are the ones making the decision to reboot. When there are many users, though, rebooting needs to be coordinated, at the very least, so as not to interrupt work in progress. And, as alluded to above, when there's real money involved, sometimes reboots are not ever acceptable.
For you, rebooting might not be evil, but some people do actually depend on high availability of their computers, and some of them are running Linux.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
If it weren't for companies like Redhat, Mandrake (Mandriva), (pre-Darl) Caldera, and Novell trying to find ways to convince people to pay for "free" software, how likely do you think it is that we would have a useful Linux today?
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Set your voicemail to "Yes, we know this is down. Check your e-mail." or some such and shut your ringer off. Works for me.
No sig for you!!
I don't really personally see any use of such service. If you need FT or HA system you need to design it as such from ground up. In this case paying 4 bucks just solves some problems with rebooting after kernel upgrade. I dont have problem with that. I just reboot in next service window. In normal situation mission critical systems have some sort of redundancy not only to cope with planned service reboots but with other unplanned disasters. So usually you have a N+1 redundant cluster in which you can reboot the servers using some procedure that was worked out while DESIGNING the system. Also I see quite few security issues with patching the kernel this way. In mission critical services you usually do test everything before rolling it out to the systems so using such feature just makes things more complicated (that just simply reboot the machine with my current procedures).
I cannot find anything about security details on their webpage. They state "Ksplice Uptrack uses cryptography to authenticate the update feed.". So what? Fedora also used cryptography and once their servers got rooted the whole chain collapsed. So if I was to use their service I wish to know how exactly their security is implemented since I would be getting kernel patches (quite critical stuff) from them. At least with RHEL I know a about their security procedures (quite rigorious). From support point of view. Does f.e. Red Hat or Oracle support systems patched this way?
It is a nice feature but IMO not suitable for enterprises yet.
but telling people to check their email when their mail server is offline probably doesn't work for them.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
"Have you tried turning it off and on again?"
"Is it definitely plugged in?"
Grammar Lesson: you're is a contraction of "you are"; your means you possess something; yore means days gone by.
Aren't most of the air traffic control servers still using hardware with tubes? I wouldn't be surprised if they haven't updated a kernel in the last 30 years.
Older hardware would be alphas or comparable hardware expected to run unix. Newer machines are more likely to be commodity servers. Kernels in use won't be cutting edge from Linus's git tree. They will be a few versions behind and integrated for the application.
Generally in ATC you can have downtime for maintenance but you have to be able to say when it will happen. As the other poster said you can reconfigure to hand off traffic to another center or another part of the same center, but it takes planning or people get upset.
http://michaelsmith.id.au
I am not talking about web servers.
http://michaelsmith.id.au
This sounds more like a Microsoft solution than a Linux solution. $48 a year is exactly $48 more than I paid for my OS. But the question is: Are we so lazy that we will pay $48 a year to not have to reboot the system? I mean lay down and take a break while its rebooting and you'll be fine.
I just place blame on the user. And when they get defensive, I point out their defensiveness as proof of their guilt. Pretty soon, they learn not to complain.
THL phish sticks
Linux is a service now?
A lot of people will think that, and it's competitors won't do anything to counter it.
"If you want the most stable version of Linux, its 4 dollars a month? And they have the nerve to call it free. After purchases Windows 8, all the patches and upgrades are free for at least 3 years."
The Kruger Dunning explains most post on
If you can't reliably restart your server on your own schedule, what makes you think it will gracefully restart when something happens that you can't control?
Well-controlled live changes are not inherent to microkernels. Monolithic design does not preclude well-controlled live changes; all you need is persistent memory and a kernel that can resume operation on that memory. Stage the new kernel and switch. This has been done for HA systems.
Can one argue that microkernels are more amenable to well-controlled live changes? Perhaps.
That's the best you can say about it. The rest is a fiction that exists exclusively in your head.
I'm not afraid of money.
I'm afraid of some startup jokers - possibly funded by TLA's - taking my money to 'root' my servers!
"Flyin' in just a sweet place,
Never been known to fail..."
I would not trust such a service. Just because a kernel can be upgraded in place doesn't necessarily guarantee that same kernel configuration will be able to boot your system in an outage. Something like a messed up GRUB configuration won't be spotted until you actually try to restart your system. I think part of a regular maintenance strategy is being able to restart your servers and make sure everything is configured to come back up automatically. The last thing you want to is to be trying to figure out what's wrong with your boot config when you have an unplanned outage.
Same goes for any other type of server, you just make sure that any non deterministic parts of your server calls are shared among the cluster. How you do this is up to you (memcached/database) just make sure it's 100% replicated.
Then when one machine stops doing what it's supposed to (or looks like it might), your heartbeat script writen for the occasion kicks in, rotates the offending machine out of the cluster and, if you really have the budget, rotates a spare into it's place which then syncs with the other machines and off you go.
Ask 8 slackers a question, get 10 awnsers (a citation, but I can't remember from who)
i can picture the guys saying that on "The I.T Crowd" .. shame they didnt make so many episodes.
It's not a typo if you understood the meaning!
How recent? Which models? Are the old machines being made available on eBay?
I am not even talking about servers. How about when there is an actual person sitting in front of a screen which is attached to the system you are updating. If it is going down you need to move that actual person (and their infrastructure: communications, etc) to a different screen, or move their job to a different person; and all without interrupting the task at hand. Thats not easy.
http://michaelsmith.id.au
> When a stock broker's trading floor system goes down, the loss is
> measured in millions of dollars per second
Ksplice does not protect you from servers going down.
> Downtime is just not acceptable under some circumstances.
Still - ksplice does not make your servers highly avialable or fault tolerant. It just allows you to patch the server without rebooting.
Any decently designed HA or FT system should have such things like service reboots implemented by design since it is natural and obvious that you will need to reboot some nodes sometimes. Usually it is reffered to as maintanance or planned downtime - it is quite other thing that an unplanned downtime or disaster recovery - ksplice does not deal with that.
Depends. Most places that require high availability have redundancy built in to the point where half of their servers can go offline and nobody (except server admins) even knows about it. But for small and mid-sized businesses that don't have those resources available, any time offline is lost work/sales/time/etc.
How recent? Which models? Are the old machines being made available on eBay?
I could have found you a dozen 11/84s and four or so 11/83s in Melbourne. They ran the traffic signal system. All I salvaged was one 19 inch rack. It holds servers at my place now.
http://michaelsmith.id.au
Years - I mean years - ago I was doing hot patches to Sun boxes that needed to stay up forever no questions.
Enter the mid 00's, when the cloud became useable. Enter the late 90s, when Beowulf made computational clustering with commodity products trivial. MCServiceGuard from...whatever year, etc etc etc.
Point is, anything that someone thinks is so important that they want to never reboot a system...should have 2 systems that cost half as much each running as a high-availability app cluster. Anyone with any sense knows that it is supposed to be a service that is always available, not a server. Patch it and reboot it, ya goofball. Let your load balancers and app clusters take care of the temporary loss of one of your servers. Why is this even a question? What semi-decent app doesn't have HA built in to it these days?
I don't think desktop machines are the problem. How many desktop machines are used 100% of the time? And really, even if you do have users who don't take eat, sleep or go to the bathroom, I think they'll probably welcome the 30 seconds a month they get off while you reboot their computer.
After all, $4/mo is pretty cheap to have a better chance of winning the BOFH penis length... er... uptime contest...
NetWare was bulletproof, for what it did.
http://www.novell.com/coolsolutions/netware/img/bartb_uptime.gif
http://www.theregister.co.uk/2001/04/12/missing_novell_server_discovered_after/
In the ATC application I support the workstations are very important. They are used 100% of the time and unanticipated downtime is a critical problem.
http://michaelsmith.id.au
What kind of stock broker system doesn't have redundancy to handle if a server goes down?
Sorry, dinner's ready or I'd go on with a lot more.
Your mom calling you to come up from the basement?
I like my neckbeard thank you very much; it keeps me warm in the server room (the servers run linux btw). And no, I don't think that applying patches to the kernel on a live production machine is typically a good idea. Sorry if that makes me a worrywart.
Get a web developer
Most clustered applications aren't active/active and fully stateful, as that raises the complexity by "quite a lot". I've got pending patches for one of the MS SQL servers that our website runs off, but failing over to the other cluster node will result in an interruption to the site while the services are stopped, the IP address etc. migrated, and everything restarts on the other server. Plus, the web application doesn't handle the temporary unavailability of the database very well, and it takes a couple of failed requests before it retries and starts working again.
The proxies sit between the web servers and the big bad internet are clustered as well (Linux-HA), but again there's a few seconds while the IP address is transitioned. This isn't so bad since in this case only on IP address needs to be relocated and no services restarted, but it does still cause a slight blip.
For many applications, having true seamless failover is very difficult. And if a few bucks a month can save you from having those 30 seconds of downtime, it could well be worth it for a lot of people.
Easier to read explanation: http://www.linux-magazine.com/w3/issue/95/052-054_ksplice.pdf. In short: it's all done with clever (Mario style) trampoline jumps.
I think the proper application of HALinux Heartbeat obviates the need for keeping a machine alive forever. There are going to be ECC parity errors that are going to take the machine down. Replacing kernel parts on-the-fly is a good ideal, though, but a higher-level view suggests that's not the real challenge for 99.999% uptime.
Kriston
Some organizations who have operational requirements to provide a service continuously. For them there is no acceptable downtime.
And they've designed their systems properly such that not only the planned - but also unplanned - outage of a single server is both non-disruptive, and transparent.
"Service" and "server" are not synonymous. This is especially true once you move outside of trivial environments. If your HA service can't sustain the outage of an individual server, then its *fundamental architecture* is broken, and what OS is running barely even counts as semantics.
In the ATC application I support the workstations are very important. They are used 100% of the time and unanticipated downtime is a critical problem.
Firstly, patching is in no way "unanticipated downtime".
Secondly, if your environment can't sustain workstations being unavailable *even on a schedule*, then it's not meeting the requirements it was supposedly designed for.
If you don't know exactly what an update touches, just reboot.
Gonna be O.K,
Dah dah duh duh,
Just reboot!
The kernel babe,
Duh duh duh duh
Just reboot!
Re-re-re-re-boot...
3.x Netware was pretty darn bulletproof, provided you didn't mind copying the Bindery stuff to every different server, and one had to use IPX or nothing.
There are three things from it that were notable:
1: If a user doesn't have access to something, it doesn't show up in a listing. No directories or files with "access denied" messages, just making them more curious.
2: The OS was simple and had very limited functionality. Want some feature? Buy a third party NLM. Netware 3.11 had next to no attack surface.
3: The console commands kept the riffraff out. No point and drool interface. To use it, you had to at know the basics of what you were doing.
The one thing I wish was passed on to modern operating systems was feature #1. Out of sight, out of mind. If a directory isn't shown, a user won't bother trying to get access to it, as opposed to something saying "permission denied".
There is also the UNIX philosophy. The endless chain of reboots was especially horrid in the 95/98/ME days where if one wanted an IP address change, or some other network item, reboot time.
UNIX machines historically were rarely rebooted, unless someone was dropping the box into single user mode for level 0 dumps and a guarentee that no other programs were touching the filesystems.
In general, there was only one reason for an unplanned UNIX reboot, and that was a dead NFS handle which locked up a machine. Almost everything else (except security or hardware issues) could wait until the next downtime window.
Oh, don't get UNIX people started about reinstalls. IMHO, only times a machine should ever be reinstalled are after a hardware failure, after a major security breach, or if going to a major version of an OS, where an upgrade would leave a ton of useless and potentially dangerous amount of cruft behind. Even in most of these cases, a bare metal restore is better than a reinstallation so that applications don't have to be reinstalled, retuned, and reconfigured.
First Microsoft is not very eager to sue anyone, second this is totally different mechanism, third Microsoft patent is an old technology - very old because it describes what we did in OS/360, OS/370 operating systems and applications a long, long time ago. Patching memory was (sometimes!) a daily routine for local systems programmer - updating live 24x7 production systems is/was fun but scary!
Anyhow - $4 is cheap when someone is doing the pre-work for you. Actually - the more modularized / structured Linux (Linux == kernel!) gets, the easier it is to support dynamic / online updates with no interruption. There are systems where you can do it already, even all(?) Unix systems allow you to change the whole object in flight if the application is written for it. Actually I designed a while ago one for Windows, load new object, kill the old and the new is automatically used for next call / request / whatever. Tandem Pathway is one very good example, Erlang as a language and a system supports it, systems with failover to another cpu / node have always supported it since Datasaab "non-stop" system from (I think?) early 70's (Cobol kernel!)
Now, giving the "skills" of current "systems programmers", I'm not sure that real time patching is a good idea? Right or wrong, today the "hard" skills, understanding operating systems, their interactions with hardware and applications, etc is very rare! Not a person problem but the documentation, the trust on products / manufacturers / providers, etc are killing the low level skills even the computers handle zeros and ones the same way as day one. And unfortunately the same problems on high level - miracle products will solve all the problems / providers and manufacturers know my problems better than my experienced employees - and I have a bridge to sell!
For home machines or desktop machines, the occasional reboot for patches is not problem.
For servers, you want to reboot after any significant change to the code running on your system, to verify the change didn't break booting. It is very annoying when a server fails to start properly after a power failure or the replacement of broken hardware, and it turns out to be due to a change someone made weeks or months ago.
Nobody in their right mind would trust a single machine if 99%, much less 99.9%, or even 99.99% uptime is required. A HA infrastructure is critical. Yes, a single machine [1] does have a good chance of running at 99% over a year, but that is pure luck.
I have seen companies run multiple HA layers. From the applications being clustered, to the VM the app runs on being clustered onto multiple machines, to multiple SANs in geographic separate areas of the US. This stuff is insanely expensive, but compared to downtime (especially for anything financial), it is a good investment.
[1]: I'm mean PCs to the rackmount Suns. An IBM mainframe with high RAS is a completely different story, as some have multiple CPUs execute the same instructions and the results compared.
It drives me crazy to see this.
Memory holes and latency go up with age on Windows.
Mainframes stay up for years and so does my themastat, DVR, and most electronic devices like it should.
http://saveie6.com/
I know at least one company which will implement it. They are a movie/video studio with a huge queue and they run Da Vinci colour correction system which runs on Linux.
Of course, machine is totally disconnected from real world (to the degree of sealed USB ports) but they could use the performance and stability enhancements of the newer kernels.
I just paid $3 for monthly last.fm service, a freaking jukebox. Some companies pay $1 M/year to IBM for Z/OS which uptime is one of the advantages... I don't understand how $4 really surprises people.
It (offering services) is in fact the GNU's answer to "How will developers make money?" question. You can even make money from your own special kernel compilations as long as you share your knowledge.
"Would someone smarter than me please explain ..."
That's a well phrased question. I like that. That's the reason why you get so many replies and learn so much more than me.
It could definately stack another 9 on 99.999
Um huh? 999.999? You mean, like making a server do the work of 10 servers?
Ohhh ... you mean service downtime. I don't know how you manage to shutdown a service, patch it, and bring it back up, within 31.5 seconds. I guess that's why you're earning the big bucks and I'm not.
What kind of IT admin at a stock exchange decides to patch the system in the middle of the trading day?
Think of security patches for 24/7 production servers, or even servers that are only critical during office hours. Do not think pc's.
What's evil is "technical" staff who started out on windows and think that a reboot is the perfect way to solve any problems. Rebooting CAUSES problems, it takes ALL your services offline when there might have only been one that had a problem.
I used to have machines at home which had been up so long, i never bothered to configure most of the services to start at boot, and i changed the network config at some point but never configured it to use the new config at boot. When that box had a power failure at around 600 days, it didn't come back online properly due to my oversight.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Kinda like the way older versions of linux would roll around at 497 days...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Give them dumb terminals where all the state is held on a server...
Dumb terminals are simple devices which shouldn't need patching and so can run non stop.
Also, the human operator will require some downtime, what's to stop you updating the terminal when the operator is sleeping? If another operator needs to take over they can do so on another terminal anyway.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I'm sure #1 is possible, at least to some level...
I have a system running selinux, and files my user doesn't have any access to show up as question marks (ie it knows a file is there, but cannot even read its filename)...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
http://forums.techarena.in/windows-update/984365.htm ' SP3 hangs at "Running Processes After Install" '
The ballsy kind.
Mental! I understand the need for ksplice, but would you trust a third party to "patch" your kernel for "security" flaws?
Free as in speech. not necessarily as in beer.
Reminds me of the old story of the University of North Carolina's "missing" Novell server.
http://www.theregister.co.uk/2001/04/12/missing_novell_server_discovered_after/
We've lost a server! No, it's still responding to pings, we just don't know where it is" - eventually found four years later behind a drywall someone had errected.
What kind of stock broker needs his system up when the markets are closed?
The newer versions of OpenSUSE use Ksplice during the installation process to switch from the kernel used on the boot CD to the kernel recently installed on your system. It's an unbelievably cool concept to patch a kernel as it's running in memory but in my experience it's not incredibly stable. I've installed 11.1 at least five times and watched the system crash at least three times during the ksplice process. It's not a big deal to me because rebooting the system lets me finish up the install, but the ksplice feature is one that I've always considered to be experimental.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
When a stock broker's trading floor system goes down, the loss is measured in millions of dollars per second
So a full day's outage would cost them $86B - or $31T a year - assuming only one million per second?
I could see that as being the value of the potential trades that couldn't be executed, but unless the broker makes 100% commission, I imagine the actually losses would be much less (although still substantial).
Dewey, what part of this looks like authorities should be involved?
Features like this should have been integrated into Linux and Windows years ago....if they cared enough to do it.
#1 is also available for Windows file shares since Windows 2003 SP1. Microsoft calls this feature "Access based enumeration".
More info: http://technet.microsoft.com/en-us/library/cc784710(WS.10).aspx
Well obviously it's not as simple as just putting in a cluster. And seamless failover is difficult. But if you need really that system availability, you can't rely on a single piece of hardware. It will eventually fail. And if you can't failover reliably for a couple of minutes for a scheduled reboot, then you're going to be screwed when you have a real problem that could take minutes, hours, days, etc... to correct. The tech is cool, but relying on it to keep a mission critical system up is a bit like using raid as your backup strategy. Not that you're saying that. But three posts up or whatever... If you've got that availability requirement, you've got to design cluster.
Can you construct some sort of rudimentary lathe?
You use slashdot, google, and so forth, right? You use akamai for practically every major web site (including Microsoft.com, Apple.com, and so forth) without even knowing it. Your router probably runs linux, and even some cars are running it now. When you fly, there is an increasingly large chance that the avionics helping your pilot navigate cross-country runs Linux (Linux is rapidly growing in the avionics field).
I know I'm only feeding the troll, but the AC can't deny that Linux has proven its usefulness and stability far above and beyond what Windows has proven. The only drawbacks it has is that installers still have some level of dependency hell (but it's better than DLL Hell which still exists to some extent) and drivers are still lacking in a few areas, notably wifi, bluetooth, and custom appliances (for my example, I'll mention embroidery machines).
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
Probably not a smart one. The point is that if they can't handle taking a server down to reboot it, how are they possibly going to handle if a server goes down due to some hardware/software error?
faggots have offal in them? I thought it was just minced pork or something like that. (I can hardly search from work or I'd check thei nternet myself)
If you can't see the value in jet powered ants you should turn in your nerd card. - Dunbal (464142)
Since when has Linux ever become useful? And useful is defined beyond the needs of a bunch of neckbeards.
Flamebait? More like "funny"...
Indeed, since when has Linux ever become useful?
I think it may have been sometime around... 1994 with maturing NCSA httpd? At least Linux became useful by the time web became useful for people beyond a bunch of neckbeards, ie. in the 90's for sure.
I have a Centos server with over 1180 days of uptime, and another of 760.
They are both thrashed pretty heavily by being used as data processing servers and the 760 days one (which has a quad Xeon with 16GB RAM) was used today to perform a MySQL load test and got to 321,000 queries per second when referencing tables with over 100 million rows, running at a load of 5-6.
Never rebooting eh ? Make sure you are using ECC memory...
http://lambda-diode.com/opinion/ecc-memory
Well it's not about need. If you really need constant availability with absolutely no interruptions, you'll have engineered something to provide that. But most people would like to have constant availability, but the reality is you can't afford to provide that, so do what they can given their resources. That often means a high-availability failover cluster, with a short disruption to services whenever the failover occurs.
An inexpensive service to allow you to avoid failovers for some classes of scheduled maintenance just gives you another tool you can use to get closer to constant availability at a price that's affordable.
Combine this with something like VMware's fault tolerance and you could get a pretty robust solution. Now you just need to be able to patch the programs providing your service in-memory and you're gold!
How you do it: - you separate your carrier servers from application servers. - Whenever you need to upgrade an application, you mark one application server after another as "out of service", so that new calls are not routed there. As soon as the last call leaves the application server, you could do whatever you want with it, reboot it or hammer it - your choice. - Carrier servers do not need updates as frequent, as they need reboots, so the problem is not really there to begin with.