Drakconf did this too, I think, it's been a long time since I've last used PCLOS2007. Very nice, though not as pretty and informative as I'd like. Though I'd give the Electra initiative priority, to get some traction on the turn-key appliance front, because virtualization is not always a good fit, OTOH, integration of configuration management with the package manager would be priceless. Imagine typing sudo apt-get install lamp-stack and having a web sever ready to be loaded? Or say sudo apt-get install lamp-stack-joomla and having CMS set up and ready to go? And, yes I know about these http://www.turnkeylinux.org/ guys - as I said, virtualization is not always a fit.
I see a market for a x86 PC with a coreboot+XenClient+IllumOS (because of ZFS) system firmware, virtualizing windows, with checksum protection of core system files and registered, with restore from original known-good snapshots, per file. Unsigned executable execution triggers a system call, in turn trapping to the hypervizor, triggering a snapshot, before the first untrusted instruction is executed. On boot the user is presented with the option of a friendly management console, allowing the installation to be reverted cleanly and securely. User data is on a separate partition, hidden, also snapshotted, and transparently integrated with the root win fs with a few registry hacks applied by the hypervizor. That data partition is set to read-only during untrusted executable execution. The hypervizor audits on every boot the autostart processes, and doesn't allow mounting of user data if an unregistered service is detected, such, upon detection are killed immediately, and executables that fail checksum aren't allowed to load. Maybe automatically set up hidden limited accounts with faked access to user data for untrusted executables, all this auditable by the hypervizor at any time.
x86 is actually a great architecture, when you get rid of some cruft (Tru64 (or was it VMS?) handled the migration to Alpha quite well - but the ugly but required for compatibility instructions not even in the microcode - but in the system firmware (SRM)). The instruction encoding could be a tad smarter - to simplify the decoder, but efficient instruction encoding is important, the memory wall has been hit, in a sense, for a long time, and efficient cache usage is a must. Segmentation is a really neat feature, which was not taken advantage of driven by pure laziness, and traditionalism (This assembly sucks! It's meant to be use by a compiler, moron. But I won't be leet anymore - so fuck off.). Register addressing could have been a little smarter - but actually, with segmentation and rings, x86 has top notch security, it's just that nobody uses it. Same thing with WinNT - great security and extensibility architecture, and it went either/both badly implemented, or/and unused.
FFS, quit feeding the damn troll! Honestly, there should be a special trolling section with no moderation on slashdot, and give moderators the ability to move whole threads over there.
Some sort of SMTP in HTTP encapsulation would be a convenient workaround, if a few big providers would use it (I bet GMail would add support about two hours before the RFC is even ratified.
ECN enforcement at the network edge would throttle the zombies if the spam victim behaves appropriately (if not, it's their problem), and not screw with outgoing network connections to other mail servers.
So I guess it's T series for me - money is still an issue - weight is not, but that W series is gotta be expensive, and I'm looking for a desktop replacement. Thanks again.;)
Power doesn't have a redundant route from socket to motherboard? Not a good idea. Power layout changes should be a non-event, modulo PSU failures. Your UPS doesn't have redundant batteries? Hell, the battery controller should be external to the UPS. And be redundant.
Hardware RAID - with no diagnostics reporting to the OS? Lame.
You give someone su, and not sudo access? That aside, some dirs need to be locked for runlevel 4 (or whatever is the production default). Not sure if linux has it, though.
No RAID, on a sever? That aside, why aren't you running your systems on PXE boot, or similar? And why didn't the OS report it losing a HDD?
Those tweaks need to be run on boot, scripted, with anacron, and request operator assistance if required, before reaching production runlevel.
Define replicate: the hardware as well? A VM ought to be fine for testing system configuration - just boot it on the production sever, from the same partition, as read-only. Weird driver interactions aside - I don't see where the problem is. Maybe if you are running the sever under a type 1 hyper-visor like Xen, you can even test the machine booting with actual drivers, if you suspend the production VM for a few seconds (don't forget the hyper-visor level caching can make booting much faster).
For the last time, XNU is not a BSD variant, no more than NT is by using the network stack... Yes, there is a larger part of the code that came from there, but the freaking HAL, and driver system have nothing to do with BSD.
Slashdot Mirror
My first linux was 2.6.23.tex5.
Rolling release and decent documentation, with some semblance of a package manager, without getting in the way.
Drakconf did this too, I think, it's been a long time since I've last used PCLOS2007. Very nice, though not as pretty and informative as I'd like. Though I'd give the Electra initiative priority, to get some traction on the turn-key appliance front, because virtualization is not always a good fit, OTOH, integration of configuration management with the package manager would be priceless. Imagine typing sudo apt-get install lamp-stack and having a web sever ready to be loaded? Or say sudo apt-get install lamp-stack-joomla and having CMS set up and ready to go?
And, yes I know about these http://www.turnkeylinux.org/ guys - as I said, virtualization is not always a fit.
I'll see your COBOL, and raise you a FORTRAN.
Which ones?
No AutoPager add-on on your FF? Turn in your geek card.
I see a market for a x86 PC with a coreboot+XenClient+IllumOS (because of ZFS) system firmware, virtualizing windows, with checksum protection of core system files and registered, with restore from original known-good snapshots, per file. Unsigned executable execution triggers a system call, in turn trapping to the hypervizor, triggering a snapshot, before the first untrusted instruction is executed. On boot the user is presented with the option of a friendly management console, allowing the installation to be reverted cleanly and securely. User data is on a separate partition, hidden, also snapshotted, and transparently integrated with the root win fs with a few registry hacks applied by the hypervizor. That data partition is set to read-only during untrusted executable execution. The hypervizor audits on every boot the autostart processes, and doesn't allow mounting of user data if an unregistered service is detected, such, upon detection are killed immediately, and executables that fail checksum aren't allowed to load. Maybe automatically set up hidden limited accounts with faked access to user data for untrusted executables, all this auditable by the hypervizor at any time.
x86 is actually a great architecture, when you get rid of some cruft (Tru64 (or was it VMS?) handled the migration to Alpha quite well - but the ugly but required for compatibility instructions not even in the microcode - but in the system firmware (SRM)). The instruction encoding could be a tad smarter - to simplify the decoder, but efficient instruction encoding is important, the memory wall has been hit, in a sense, for a long time, and efficient cache usage is a must. Segmentation is a really neat feature, which was not taken advantage of driven by pure laziness, and traditionalism (This assembly sucks! It's meant to be use by a compiler, moron. But I won't be leet anymore - so fuck off.). Register addressing could have been a little smarter - but actually, with segmentation and rings, x86 has top notch security, it's just that nobody uses it. Same thing with WinNT - great security and extensibility architecture, and it went either/both badly implemented, or/and unused.
Do those backhoes have any armor plating? http://xkcd.com/705/
FFS, quit feeding the damn troll! Honestly, there should be a special trolling section with no moderation on slashdot, and give moderators the ability to move whole threads over there.
Paypal sucks, use bitcoin. Apache Wave would be a good fit for the software itself.
Your CFLs are probably sucky - if they aren't may I recommend moving to LED fixtures?
LEDs rule - nearly invisible in the IR.
Ever try LEDs?
The FSC AMILO I'm typing this comment on has a 1.4 GHz Celeron M CPU, 2 x 256 MB DDR1 RAM. What do you think?
Linux is no less a sever platform. PBI are filesystem deltas, AFAIK - fs dedupe should take care of it, partially.
Some sort of SMTP in HTTP encapsulation would be a convenient workaround, if a few big providers would use it (I bet GMail would add support about two hours before the RFC is even ratified.
ECN enforcement at the network edge would throttle the zombies if the spam victim behaves appropriately (if not, it's their problem), and not screw with outgoing network connections to other mail servers.
So I guess it's T series for me - money is still an issue - weight is not, but that W series is gotta be expensive, and I'm looking for a desktop replacement. Thanks again. ;)
System imaging and net-boot.
Power doesn't have a redundant route from socket to motherboard? Not a good idea. Power layout changes should be a non-event, modulo PSU failures. Your UPS doesn't have redundant batteries? Hell, the battery controller should be external to the UPS. And be redundant.
Thanks.
Not to be annoying, but how do the series compare, i.e. pros/cons?
Define replicate: the hardware as well? A VM ought to be fine for testing system configuration - just boot it on the production sever, from the same partition, as read-only. Weird driver interactions aside - I don't see where the problem is. Maybe if you are running the sever under a type 1 hyper-visor like Xen, you can even test the machine booting with actual drivers, if you suspend the production VM for a few seconds (don't forget the hyper-visor level caching can make booting much faster).
For the last time, XNU is not a BSD variant, no more than NT is by using the network stack... Yes, there is a larger part of the code that came from there, but the freaking HAL, and driver system have nothing to do with BSD.