If you don't have the skills (and even if you do) it is likely cheaper to upgrade your unsupported hardware than pay for the developer to maintain the code. Or spend your own time doing so. To use the example of video cards (recent 3dfx hardware support drop) - you can buy a 3d card that will outperform the voodoo2 these days for about $50 or less. If you value your free time at even a rate as low as $5/hr, you're still going to be far better off just stumping up for new hardware than attempting to carry prehistoric gear into the 21st century.
Pretty much this. I've been burned by shit in linux like NIC drivers swapping load order, and turning my outside interface into my inside and vice versa on a kernel upgrade. This sort of shit just doesn't need to happen.
*BSD has its issues also, however I will make this comment to any Linux users who are considering testing *BSD and scared of learning new stuff.: I started in 1999 and stuff in the FreeBSD handbook that was valid back then mostly holds true today.
There are many changes going on in the OS behind the scenes, but as far as the user is concerned once you DO learn the BSD way, you very rarely need to un-learn and re-learn stuff due to random changes.
More importantly for me, freebsd has always (since i started playing with it vs linux in about 1999) been far more resilient under load.
Load a Linux machine up past a load of say 4 on a single cpu machine and things used to get rather unresponsive. Do the same on FreeBSD and you can have loads of 10 or 15 with less appreciable drop in responsiveness. Sure tasks may take longer to run, but the system still responds to user input, sound doesn't click or stutter, etc.
I haven't stress tested a Linux box in a few years, so I'm not sure if the same holds true, but the scheduler shenannigans of a few years back were caused by this exact issue.
Just because the kernel is 30 meg, it doesn't mean that execution is running through all the unused drivers at runtime. an additional 27mb of ram on a machine with 1gb (or more) is such a piss in the ocean (as far as application speed is concerned) it is not worth worrying about. I suspect the vast majority of any speedup you'll be getting with custom kernels is for optimizations related to your CPU type.
Is the question you need to answer. Decent emulation of old hardware often requires fairly hefty CPU - and there's no getting around that (other than trading off frame rate or accuracy).
I suspect you may (counter-intuitively) find more success with large cased desktop hardware than the small form factor laptop style hardware - the reason for this is that large fans make less noise for the same airflow than small high speed ones.
Sure, a mini, laptop, etc is fairly quite when it is idle. Ramp up the CPU however and they sound like a turbine. A desktop will have some fan noise at idle, but it won't ramp up much under load.
I doubt that a passively cooled system will provide enough cpu power to run emulation at an acceptable frame-rate, other than for rather old hardware, in a somewhat inaccurate manner, however depending on the emulators required, YMMV.
And windows is different? At least the mac ships with a command line worth shit, it took microsoft until he release of powershell to even start playing the same sport on that front, let alone in the ballpark.
Its still missing an equivalent to Automator and Applescript.
Noobs who parrot the old "macs r for retards!!!" argument have clearly never used one and have no idea what tools are available to get shit done far quicker and easier than anything on Windows or Linux.
I think you're a little fast to write off ARM in the server spaec. 99.99% of servers are memory bottlenecked. CPUs resources have been more than plentiful for most servers for years now. Throwing more CPU at the problem, for most tasks, simply isn't going to win you anything - you'll just have a higher percentage of your CPU time idle.
Power consumption, size, and heat are all concerns. If you can build a blade with the same ram capacity in half the space and heat with an ARM, then if the cpu is "fast enough" it may well be a net win.
This is why microsoft has been pushing the.net virtual machine i am guessing. JIT compilation + virtual machine = CPU agnostic code = freedom from dependence on x86.
Oh, and in the server space for VMs, RAM is still the limiting factor. My little work cluster has 128gb of RAM, with 32 xeon cores. CPU is probably running at 15-30%, RAM however, is getting tight.
If you're running numerous VMs, RAM is your problem. Given enough RAM, a core 2 duo will run several VMs in a test environment just fine. With 4GB ram, you can throw the fastest CPU at it you like; if you start running into swap, you're fucked.
In fact, that goes for almost every non-gaming task you'd use a box for these days, other than transcoding video and a few other CPU bound niche tasks.
Not to mention speeds really haven't gone up as it used to be (not to mention clock speeds, but yeah the MHz is a myth)
Depends how you measure. I've recently gone from a Q6600 Core2 Quad, to an i7 2720 in my new macbook pro. Yes, desktop, to mobile CPU.
The i7 kicks the living shit out of my Core2 in transcoding video. Sure its a bit of a niche task, but CPUs have in general been "fast enough" for the day to day non-niche desktop crap since the original pentium, really.
The K6 and previous had a pretty crappy FPU. And in the days of the Quake 1 and 2 engines, where 3d now was not in use yet, they made for a pretty shitty gameplay experience. No games? They were fine. But if you were in any way into 3d, they were crap.
Even "better" would be if you were to mess with the FTP daemon, to silently serve various files from elsewhere that are trojanned. Leave the on-server source in tact, as its obvious people are going to check that...
very much doubt it. the whole point of the keynote is that people don't know what the new and shiny is until they stay up late to watch it, attend in person, etc.
2 lost iPhones from the company in several years = standard field testing by engineers who drink beer (who would have thought it), i very much doubt it is strategy. the whole point behind apple's keynote address release style is that people DON'T have advance notice of what the new shiny looks like.
Slashdot Mirror
If you don't have the skills (and even if you do) it is likely cheaper to upgrade your unsupported hardware than pay for the developer to maintain the code. Or spend your own time doing so. To use the example of video cards (recent 3dfx hardware support drop) - you can buy a 3d card that will outperform the voodoo2 these days for about $50 or less. If you value your free time at even a rate as low as $5/hr, you're still going to be far better off just stumping up for new hardware than attempting to carry prehistoric gear into the 21st century.
Pretty much this. I've been burned by shit in linux like NIC drivers swapping load order, and turning my outside interface into my inside and vice versa on a kernel upgrade. This sort of shit just doesn't need to happen.
*BSD has its issues also, however I will make this comment to any Linux users who are considering testing *BSD and scared of learning new stuff.: I started in 1999 and stuff in the FreeBSD handbook that was valid back then mostly holds true today.
There are many changes going on in the OS behind the scenes, but as far as the user is concerned once you DO learn the BSD way, you very rarely need to un-learn and re-learn stuff due to random changes.
More importantly for me, freebsd has always (since i started playing with it vs linux in about 1999) been far more resilient under load.
Load a Linux machine up past a load of say 4 on a single cpu machine and things used to get rather unresponsive. Do the same on FreeBSD and you can have loads of 10 or 15 with less appreciable drop in responsiveness. Sure tasks may take longer to run, but the system still responds to user input, sound doesn't click or stutter, etc.
I haven't stress tested a Linux box in a few years, so I'm not sure if the same holds true, but the scheduler shenannigans of a few years back were caused by this exact issue.
Just because the kernel is 30 meg, it doesn't mean that execution is running through all the unused drivers at runtime. an additional 27mb of ram on a machine with 1gb (or more) is such a piss in the ocean (as far as application speed is concerned) it is not worth worrying about. I suspect the vast majority of any speedup you'll be getting with custom kernels is for optimizations related to your CPU type.
We aren't still running OS 9, and it hasn't been on sale for 10+ years. Try harder.
Is the question you need to answer. Decent emulation of old hardware often requires fairly hefty CPU - and there's no getting around that (other than trading off frame rate or accuracy).
I suspect you may (counter-intuitively) find more success with large cased desktop hardware than the small form factor laptop style hardware - the reason for this is that large fans make less noise for the same airflow than small high speed ones.
Sure, a mini, laptop, etc is fairly quite when it is idle. Ramp up the CPU however and they sound like a turbine. A desktop will have some fan noise at idle, but it won't ramp up much under load.
I doubt that a passively cooled system will provide enough cpu power to run emulation at an acceptable frame-rate, other than for rather old hardware, in a somewhat inaccurate manner, however depending on the emulators required, YMMV.
the use of alt.binaries and IRC DCC has had a huge resurgence.
Uh.
And windows is different? At least the mac ships with a command line worth shit, it took microsoft until he release of powershell to even start playing the same sport on that front, let alone in the ballpark.
Its still missing an equivalent to Automator and Applescript.
Noobs who parrot the old "macs r for retards!!!" argument have clearly never used one and have no idea what tools are available to get shit done far quicker and easier than anything on Windows or Linux.
I think you're a little fast to write off ARM in the server spaec. 99.99% of servers are memory bottlenecked. CPUs resources have been more than plentiful for most servers for years now. Throwing more CPU at the problem, for most tasks, simply isn't going to win you anything - you'll just have a higher percentage of your CPU time idle.
Power consumption, size, and heat are all concerns. If you can build a blade with the same ram capacity in half the space and heat with an ARM, then if the cpu is "fast enough" it may well be a net win.
This is why microsoft has been pushing the .net virtual machine i am guessing. JIT compilation + virtual machine = CPU agnostic code = freedom from dependence on x86.
Have run games under rosetta. Its "ok" on decent hardware.
Actually the "fair" comparison would be to use the compiler most third party software out there uses.
Oh, and in the server space for VMs, RAM is still the limiting factor. My little work cluster has 128gb of RAM, with 32 xeon cores. CPU is probably running at 15-30%, RAM however, is getting tight.
If you're running numerous VMs, RAM is your problem. Given enough RAM, a core 2 duo will run several VMs in a test environment just fine. With 4GB ram, you can throw the fastest CPU at it you like; if you start running into swap, you're fucked.
In fact, that goes for almost every non-gaming task you'd use a box for these days, other than transcoding video and a few other CPU bound niche tasks.
ECC is nice, sure - but if you buy RAM that works its not really necessary.
Depends how you measure. I've recently gone from a Q6600 Core2 Quad, to an i7 2720 in my new macbook pro. Yes, desktop, to mobile CPU.
The i7 kicks the living shit out of my Core2 in transcoding video. Sure its a bit of a niche task, but CPUs have in general been "fast enough" for the day to day non-niche desktop crap since the original pentium, really.
The K6 and previous had a pretty crappy FPU. And in the days of the Quake 1 and 2 engines, where 3d now was not in use yet, they made for a pretty shitty gameplay experience. No games? They were fine. But if you were in any way into 3d, they were crap.
Not using SSH key pairs for accounts on a public system like this sounds pretty brain damaged to me.
Even "better" would be if you were to mess with the FTP daemon, to silently serve various files from elsewhere that are trojanned. Leave the on-server source in tact, as its obvious people are going to check that...
Maybe even replacements for the git tools, too.
Did they discover this compromise by chance, or were they running an IDS and picked it up instantly/within a day or so?
If they've been compromised for months, then there are potentially millions of users affected.
Just because there have been no kernel-related security announcements, it doesn't mean that there have not been kernel releated security compromises.
very much doubt it. the whole point of the keynote is that people don't know what the new and shiny is until they stay up late to watch it, attend in person, etc.
2 lost iPhones from the company in several years = standard field testing by engineers who drink beer (who would have thought it), i very much doubt it is strategy. the whole point behind apple's keynote address release style is that people DON'T have advance notice of what the new shiny looks like.
Desperately poor? They're only 40bn in debt, which pales in comparison to the USA.
So you're saying its a debian vulnerability....