Well, then let's agree that everybody else copied it because it wasn't as radical to the wrist as all those radical designs.
So let me get this straight. Your idea of "radical" is NOT the fundamental redesign from a briefcase-like luggable, to a clamshell, but the minor modification of moving the keyboard back a few inches ?
W.T.F. ?
Oh, before I forget: Where would you put the trackball/-pad in your radical design? The back of the screen?
There were actually quite a few laptops that had a thumb-ball mounted on the screen or behind the keyboard, with buttons on the back of the screen, and it worked quite well (certainly no worse than the trackpad or trackpoint options that have persisted today).
All pointing devices on laptops suck. Choosing which one sucks less, is a matter of personal preference.
The Compaq LTE did not push the keyboard to the top of the lower case. It had the keyboard at the front, just like the Macintosh Portable that came out a month before. There were other computers with the hinge at the back of the lower case.
Apple was first with the palm rest.
That seems something of an abuse of the term "radical design".
4. Work ten months.
5. Get an unlimited "C" work permit/visa.
10 months ? It takes 5 *years* of permanent residency for a US Citizen to be eligible for a C Permit in Switzerland (and it wasn't that long ago it was 10 years, like it is for most other non-EU nationalities) - and being "eligible" is in no way a rubber stamp for being "approved".
Your steps 2 and 3 are also very optimistic, given that an American won't even be _considered_ for a Swiss job until the Swiss and EU applicants have turned it down.
Switzerland is a very closed market, from the perspective of foreigners being employed. Especially if you're non-EU.
Apple's laptops are much more traditional than their desktops, and sell much better.
They only appear to be traditional, because every laptop maker on earth abandoned the traditional designs and copied Apple's radical Powerbook design in the early 90s.
It's rather amusing that your own link disproves your claim.
Compaq LTE: Released October 1989 (first "traditional" looking clamshell laptop).
Macintosh Portable: Released September 1989 (still not quite a "traditional" clamshell - you need the 1991 PowerBook for that).
If you're buying it to run a business that pulls in, say, half a million bucks a year, then the ~$1500 or so (amortised over 2-3 years) "rip off" factor is little more than a rounding error.
The problem being that you're paying $100 per month in perpetuity. Sometimes you get awarded capital to spend on things in a lump sum, whereas the ability to garner a revenue commitment could not necessarily be made.
At the spend rates you mentioned, that's a basic server per year. Say the server is expected to last 5-8 years, that'll be an outlay of at least $6000-$9600+, with more to spend if you want to keep things running.
That would cover the cost of a couple of generations worth of hardware, depending on how it was implemented.
Your math does not appear to account for the other components necessary to meet similar uptimes to a hosted environment. Eg: multiple internet connections, redundant networking equipment, multiple power feeds, UPSes, disaster recovery site, etc.
My question: Is it better to go with a newer computer setup that falls within that budget, or go with the cluster. I will be doing image analysis work of function MRI data. Thanks.
While I'm not an expert on the topic by any means, I would expect for that sort of budget you'll get far better performance out of a single a machine, than any cluster you could build for the same cost.
Even if your interest is in testing how "cluster friendly" your code is (eg: for scaling considerations), you'll almost certainly still get the best performance/$ with a single quad-core machine running $CORE_COUNT VMs to "simulate" a cluster (with each VM bound to a specific CPU core).
I just can't see why you would want to venture into the cost inefficiencies of multiple machines until you _had_ to be cause a single machine wasn't fast enough - and you can fit a *lot* of power into a single computer these days.
And you're done. Oh, make sure to disable tcp_checksum_offloading on your webservers, else LVS won't work that well (read: not at all).
Just a heads-up for those who (like me) read this and thought: "WTF ? LVS works fine with TOE", it is a problem specific to running LVS in Xen VMs where the directors and realservers share the same Xen host. Link.
You'll need something that detects the primary server is offline and switches to the backup automatically. You might also want to have a separate database server that mirrors the primary DB if you're storing a lot of user content, plus a backup for it (though the backup DB server could always be the same physical machine as one of the backup webservers).
On this note, if you're comfortable (and your application is compatible) with Linux+Apache, then heartbeat and DRBD will do this and are relatively simple to get up and running. Just avoid trying to use the heartbeat v2-style config (for simplicity), make sure both the database and apache are controlled by heartbeat, and don't forget to put your DB on the DRBD-replicated disk (vastly simpler than trying to deal with DB-level replication, and more than adequate for such a low load).
Oh, and don't forget to keep regular backups of your DB somewhere else other than those two machines.
Anyway, keep dreaming... the world has changed, and those who insist on standing in place "in the name of stability" will be left behind.
What's funny is - thoroughly demonstrated by your "examples" - you still don't understand what "platform stability" means, nor why it is critical to a properly run IT infrastructure.
I'd like every program I run to be in a sandbox. For example, not having access to a single file without my permission.
It's pretty trivial to attempt this sort of thing with either Windows or any UNIXish OS. If you do, it shouldn't take long to figure out why it's completely impractical.
As platforms get older, the cost of support rises, as does the cost of adding new features or services; additionally, it often doesn't make sense to repurpose a machine when a newer one can do a better job cheaper, and has a larger base of capable programmers and support personnel. We don't use 12" green-screen or amber monitors any more for a reason - they're not cost-effective. If we're smart, we don't use a mix of older and newer versions of operating systems because it's easier and cheaper to maintain everything if it's all up to date (I'm not talking pseudo-operating systems like Windows, obviously. An OS that can't easily run headless, tail-less, and without a graphics card is not a real operating system - it's a pistache of ____ [fill in the blank] ).
I had my suspicions, but that's for actually confirming you don't have a clue what you're talking about.
It doesn't make sense, when using an OS such as *bsd or linux, to not keep current.
The BSDs don't have the problem Linux does. They *do* maintain a stable platform, as do the proper UNIXes like Solaris. The only platform that has serious issues with legacy support, backwards compatibility and dependency hell, is Linux (which, as I said, is the main reasons distros like Red Hat and SuSe exist - to swim against the tide of "release early, release often" and provide the stable platform that businesses want).
Not costing you money (lots of it, as far as I can guess) is also relevant when choosing a file server, especially when you can get Linux distributions for free that have had the capability to do a "minimal install" for as long as they've existed. Surely even a very Windows-centric company can manage to meet their file serving needs using Samba.
The cost of licensing for a Windows fileserver is insignificant, when compared to the personnel cost of trying to integrate and maintain a Linux machine in a Windows-centric infrastructure.
That is SO full of it that I don't know where to start. For example, I spent all week shelled into a BSD box in New York... BSD 4.8-RELEASE - April 3rd, 2003. Do you really want to try deploying on that platform w/o doing serious updates? STABLE != FOSSILIZED; when you look at the application stack, sticking with something from 15 years ago means you can't even find too many people who can work with it without significant loss of productivity, or worse - project failure.
A stable platform isn't one that is never updated, patched, or improved. It's one where you can be reasonably confident will remain compatible for longer than the typical Linux hacker's attention span.
Release early, release often. What you're talking about is so last century. It's not practical when targets move so fast.
What I'm talking about is how real businesses and people expect to operate.
Or have you conveniently forgotten all the problems with different 3-4d party Windows apps interfering not only with each other, but also with bringing down the OS?
Unless you're talking about conflicting software dependencies, which I can't imagine you are, this is completely irrelevant to the discussion.
A "stable platform over a reasonable time" is a couple of years.
Maybe if you're a Linux hacker. Responsible developers and the people and businesses who rely on them, however, consider a stable platform to be one that lasts on the order of 5-10 years minimum.
None of that makes the slightest difference to my point, which is that the DRM is ultimately an attribute of the media, not the player. Removing the DRM from the player will not remove it from the media, it will just stop you being able to use the media. Further, having DRM in the player, in the absence of DRM-encumbered media, is irrelevant (because it does nothing).
As I said originally, if DRM annoys you then you need to complain to the people who put it there, not the people who are required to enforce it so they can get a playback license. Vista does not restrict you any more than any other DRM capable playback tool will.
I think way back when it was NT....yeah, it qualified for like 2 parts of the C2 regiment, but, basically for it to be compliant, you could not have it connected to any networks.
That's because one of the requirements to pass was that the machine not be connected to a network.
It prevents you from sending your audio playing from your pc to your airport express. BIG warnings about the protected audio path and it stops it from working.
Google is unhelpful in providing corroboration for this claim. Evidence ?
Oh, dont own a HDCP compliant monitor AND video card? cant watch HD content. it downscaled it.
This is simply false. HD content plays fine, at full resolution, even over VGA outputs.
*DRM encumbered* HD content, OTOH, is probably a different story (although I don't think any exists) - but you will get the same downscaling no matter what device you play it back on, if you don't have a HDCP capable output device.
No, I have to complain to the company that wrote the OS code that implements restrictions that don't stop copying, but do stop lawful use.
Removing the DRM from Vista, will not remove it from the media. Your DRM-encumbered media will not be accessible *at all* without a DRM-capable player. Vista is not doing anything more than standalone player appliances.
Therefore, the only rational target to get the DRM removed are the people who put it there in the first place, the content provider. Removing the DRM capabilities from the playback tool achieves nothing.
Try that with Windows. There is no "alternate package supplier".
Yes, there is. That would be every third-party software developer who makes Windows software.
The point, however, is that in Windows (and most other non-GNU platforms), the fundamental problem itself (unknown or broken dependencies) surfaces so infrequently that it may as well be nonexistant. Other platforms and communities place a substantial priority on legacy support and backwards compatibility whereas the general Linux community does not. Indeed, one of the biggest reasons for vendors like SuSe and Red Hat existing is their work against the prevailing attitude to maintain a stable platform over a reasonable period of time.
Slashdot Mirror
Well, then let's agree that everybody else copied it because it wasn't as radical to the wrist as all those radical designs.
So let me get this straight. Your idea of "radical" is NOT the fundamental redesign from a briefcase-like luggable, to a clamshell, but the minor modification of moving the keyboard back a few inches ?
W.T.F. ?
Oh, before I forget: Where would you put the trackball/-pad in your radical design? The back of the screen?
There were actually quite a few laptops that had a thumb-ball mounted on the screen or behind the keyboard, with buttons on the back of the screen, and it worked quite well (certainly no worse than the trackpad or trackpoint options that have persisted today).
All pointing devices on laptops suck. Choosing which one sucks less, is a matter of personal preference.
The Compaq LTE did not push the keyboard to the top of the lower case. It had the keyboard at the front, just like the Macintosh Portable that came out a month before. There were other computers with the hinge at the back of the lower case.
Apple was first with the palm rest.
That seems something of an abuse of the term "radical design".
4. Work ten months.
5. Get an unlimited "C" work permit/visa.
10 months ? It takes 5 *years* of permanent residency for a US Citizen to be eligible for a C Permit in Switzerland (and it wasn't that long ago it was 10 years, like it is for most other non-EU nationalities) - and being "eligible" is in no way a rubber stamp for being "approved".
Your steps 2 and 3 are also very optimistic, given that an American won't even be _considered_ for a Swiss job until the Swiss and EU applicants have turned it down.
Switzerland is a very closed market, from the perspective of foreigners being employed. Especially if you're non-EU.
Apple's laptops are much more traditional than their desktops, and sell much better.
They only appear to be traditional, because every laptop maker on earth abandoned the traditional designs and copied Apple's radical Powerbook design in the early 90s.
It's rather amusing that your own link disproves your claim.
Compaq LTE: Released October 1989 (first "traditional" looking clamshell laptop).
Macintosh Portable: Released September 1989 (still not quite a "traditional" clamshell - you need the 1991 PowerBook for that).
Honest question: Who buys these things?
If you're buying it to run a business that pulls in, say, half a million bucks a year, then the ~$1500 or so (amortised over 2-3 years) "rip off" factor is little more than a rounding error.
Wake me up when they make a nice, expandable, mid ranged desktop class Mac.
Amazingly, that now pretty much describes the bottom end Mac Pro...
...Except for the price tag.
Have you actually worked with DRBD?
We have about half a dozen pairs of machines performing failover and replication with heartbeat+DRBD.
Well, you're dead in the water until you can convince at least one to play nice again.
Generally it's not an issue. Disconnect, set it "out of date", reconnect.
The problem being that you're paying $100 per month in perpetuity. Sometimes you get awarded capital to spend on things in a lump sum, whereas the ability to garner a revenue commitment could not necessarily be made.
At the spend rates you mentioned, that's a basic server per year. Say the server is expected to last 5-8 years, that'll be an outlay of at least $6000-$9600+, with more to spend if you want to keep things running.
That would cover the cost of a couple of generations worth of hardware, depending on how it was implemented.
Your math does not appear to account for the other components necessary to meet similar uptimes to a hosted environment. Eg: multiple internet connections, redundant networking equipment, multiple power feeds, UPSes, disaster recovery site, etc.
My question: Is it better to go with a newer computer setup that falls within that budget, or go with the cluster. I will be doing image analysis work of function MRI data. Thanks.
While I'm not an expert on the topic by any means, I would expect for that sort of budget you'll get far better performance out of a single a machine, than any cluster you could build for the same cost.
Even if your interest is in testing how "cluster friendly" your code is (eg: for scaling considerations), you'll almost certainly still get the best performance/$ with a single quad-core machine running $CORE_COUNT VMs to "simulate" a cluster (with each VM bound to a specific CPU core).
I just can't see why you would want to venture into the cost inefficiencies of multiple machines until you _had_ to be cause a single machine wasn't fast enough - and you can fit a *lot* of power into a single computer these days.
And you're done. Oh, make sure to disable tcp_checksum_offloading on your webservers, else LVS won't work that well (read: not at all).
Just a heads-up for those who (like me) read this and thought: "WTF ? LVS works fine with TOE", it is a problem specific to running LVS in Xen VMs where the directors and realservers share the same Xen host. Link.
You'll need something that detects the primary server is offline and switches to the backup automatically. You might also want to have a separate database server that mirrors the primary DB if you're storing a lot of user content, plus a backup for it (though the backup DB server could always be the same physical machine as one of the backup webservers).
On this note, if you're comfortable (and your application is compatible) with Linux+Apache, then heartbeat and DRBD will do this and are relatively simple to get up and running. Just avoid trying to use the heartbeat v2-style config (for simplicity), make sure both the database and apache are controlled by heartbeat, and don't forget to put your DB on the DRBD-replicated disk (vastly simpler than trying to deal with DB-level replication, and more than adequate for such a low load).
Oh, and don't forget to keep regular backups of your DB somewhere else other than those two machines.
Anyway, keep dreaming ... the world has changed, and those who insist on standing in place "in the name of stability" will be left behind.
What's funny is - thoroughly demonstrated by your "examples" - you still don't understand what "platform stability" means, nor why it is critical to a properly run IT infrastructure.
I'd like every program I run to be in a sandbox. For example, not having access to a single file without my permission.
It's pretty trivial to attempt this sort of thing with either Windows or any UNIXish OS. If you do, it shouldn't take long to figure out why it's completely impractical.
As platforms get older, the cost of support rises, as does the cost of adding new features or services; additionally, it often doesn't make sense to repurpose a machine when a newer one can do a better job cheaper, and has a larger base of capable programmers and support personnel. We don't use 12" green-screen or amber monitors any more for a reason - they're not cost-effective. If we're smart, we don't use a mix of older and newer versions of operating systems because it's easier and cheaper to maintain everything if it's all up to date (I'm not talking pseudo-operating systems like Windows, obviously. An OS that can't easily run headless, tail-less, and without a graphics card is not a real operating system - it's a pistache of ____ [fill in the blank] ).
I had my suspicions, but that's for actually confirming you don't have a clue what you're talking about.
It doesn't make sense, when using an OS such as *bsd or linux, to not keep current.
The BSDs don't have the problem Linux does. They *do* maintain a stable platform, as do the proper UNIXes like Solaris. The only platform that has serious issues with legacy support, backwards compatibility and dependency hell, is Linux (which, as I said, is the main reasons distros like Red Hat and SuSe exist - to swim against the tide of "release early, release often" and provide the stable platform that businesses want).
Not costing you money (lots of it, as far as I can guess) is also relevant when choosing a file server, especially when you can get Linux distributions for free that have had the capability to do a "minimal install" for as long as they've existed. Surely even a very Windows-centric company can manage to meet their file serving needs using Samba.
The cost of licensing for a Windows fileserver is insignificant, when compared to the personnel cost of trying to integrate and maintain a Linux machine in a Windows-centric infrastructure.
That is SO full of it that I don't know where to start. For example, I spent all week shelled into a BSD box in New York ... BSD 4.8-RELEASE - April 3rd, 2003. Do you really want to try deploying on that platform w/o doing serious updates? STABLE != FOSSILIZED; when you look at the application stack, sticking with something from 15 years ago means you can't even find too many people who can work with it without significant loss of productivity, or worse - project failure.
A stable platform isn't one that is never updated, patched, or improved. It's one where you can be reasonably confident will remain compatible for longer than the typical Linux hacker's attention span.
Release early, release often. What you're talking about is so last century. It's not practical when targets move so fast.
What I'm talking about is how real businesses and people expect to operate.
Or have you conveniently forgotten all the problems with different 3-4d party Windows apps interfering not only with each other, but also with bringing down the OS?
Unless you're talking about conflicting software dependencies, which I can't imagine you are, this is completely irrelevant to the discussion.
A "stable platform over a reasonable time" is a couple of years.
Maybe if you're a Linux hacker. Responsible developers and the people and businesses who rely on them, however, consider a stable platform to be one that lasts on the order of 5-10 years minimum.
None of that makes the slightest difference to my point, which is that the DRM is ultimately an attribute of the media, not the player. Removing the DRM from the player will not remove it from the media, it will just stop you being able to use the media. Further, having DRM in the player, in the absence of DRM-encumbered media, is irrelevant (because it does nothing).
As I said originally, if DRM annoys you then you need to complain to the people who put it there, not the people who are required to enforce it so they can get a playback license. Vista does not restrict you any more than any other DRM capable playback tool will.
I think way back when it was NT....yeah, it qualified for like 2 parts of the C2 regiment, but, basically for it to be compliant, you could not have it connected to any networks.
That's because one of the requirements to pass was that the machine not be connected to a network.
What does the DRM stop me from doing?
Absolutely nothing that any other device capable of playing back the DRM-encumbered media wouldn't also stop you from doing.
The fundamental problem is not the DRM-capable playback device, it is the DRM-encumbered *media*.
It prevents you from sending your audio playing from your pc to your airport express. BIG warnings about the protected audio path and it stops it from working.
Google is unhelpful in providing corroboration for this claim. Evidence ?
Oh, dont own a HDCP compliant monitor AND video card? cant watch HD content. it downscaled it.
This is simply false. HD content plays fine, at full resolution, even over VGA outputs.
*DRM encumbered* HD content, OTOH, is probably a different story (although I don't think any exists) - but you will get the same downscaling no matter what device you play it back on, if you don't have a HDCP capable output device.
No, I have to complain to the company that wrote the OS code that implements restrictions that don't stop copying, but do stop lawful use.
Removing the DRM from Vista, will not remove it from the media. Your DRM-encumbered media will not be accessible *at all* without a DRM-capable player. Vista is not doing anything more than standalone player appliances.
Therefore, the only rational target to get the DRM removed are the people who put it there in the first place, the content provider. Removing the DRM capabilities from the playback tool achieves nothing.
They're fine additions, but I'd rather read how MS is spending more time/energy addressing fundamental problems in Windows like security.
For example ?
On the other hand, I still can't play a fucking DVD on my secondary display... on Windows, that is. Or, I should say, without using VLC :)
Well the fact VLC can do it clearly indicates the problem isn't with Windows... :)
Try that with Windows. There is no "alternate package supplier".
Yes, there is. That would be every third-party software developer who makes Windows software.
The point, however, is that in Windows (and most other non-GNU platforms), the fundamental problem itself (unknown or broken dependencies) surfaces so infrequently that it may as well be nonexistant. Other platforms and communities place a substantial priority on legacy support and backwards compatibility whereas the general Linux community does not. Indeed, one of the biggest reasons for vendors like SuSe and Red Hat existing is their work against the prevailing attitude to maintain a stable platform over a reasonable period of time.