It will BSOD on boot, yes, but there is a standard, supported, and reliable way of fixing it. It's called an in-place upgrade install mode, which is the second repair option when booting the 2000/XP/2003 install CDs.
Basically, you "upgrade" Windows to the same version. What this does is it re-detects all hardware configuration, including storage, but leaves the software configuration unchanged. It can be used to move from non-ACPI to ACPI, change the HAL, fix storage drivers, and a bunch of other things. The downside is that hotfixes and IP settings are lost, so it takes a bit more work afterwards -- the server has to be patched and reconfigured a little bit.
These days, I tend to restore Windows servers to virtual machines, out-of-place. As you mentioned, it provides the opportunity to simplify the drivers, and it's possible to take a snapshot immediately after the restore. That way, if any post-restore repair steps fail or corrupt the system, I don't have to start the restore from the beginning. That does wonders for things like Exchange server restores. One of the most successful DR jobs I've done was to recover a ~250GB Exchange database to an ESX server. I cloned it out four times using thin-cloning, which takes just seconds, and then tried four different database repair methods in parallel. It was doing 60K IOPS sustained! 8)
I've had similar experience, but I've found that it swings back toward disk in a big way on the low-end. If you can fit your data onto a single 2TB disk, then it's much more reliable than tape, and cheaper too.
Tape is also a lot less reliable outside data centres, because practically nobody designs those drives to survive the dust in a typical office environment. I've seen about 50% or more of the tape systems out in the field fail at least once a year, but I've never seen a disk based backup system fail. Note once, not ever.
Also, tapes aren't as robust as people think they are. One of the hardest IT troubleshooting jobs I've ever worked on was a tape system that had regular failures. Turned out that the IT guy liked to throw the tapes up in the air (only about a foot or two), and then catch them. He didn't drop them or anything, but that was enough to cause regular backup failures. That's less robust than a (powered off) disk drive.
I've got a feeling that tape reliability numbers are massively exaggerated in marketing materials. For example, I once had a tape getting repeatedly loaded, read a little bit, and then unloaded overnight because of a software bug. It was destroyed. Think grooves etched into the plastic casing, and the tape worn to the point of transparency. That got me thinking, and I looked up the numbers.
People get confused by numbers like "1,000,000 passes" in the specifications. You have to read the full version: "1,000,000 passes on any area of tape, equates to over 20,000 end to end passes/260 full tape backups". People forget that LTO makes many passes per backup, so suddenly you're down to a three digit number of backups instead of the huge sounding million they start with in the brochure. Throw in verify-after-backup, and it's only 130. If you back up daily, that's just over four months before your tapes are worn out, according to the spec. Meanwhile, even consumer grade hard drives can last for years, even decades.
I hope you're a troll, because if you're not, this is just about the most insanely fucked up attitude to data protection I've ever seen.
A blind "Let's just backup the whole server" isn't an effective backup strategy...
If I was your boss I'd fire you on the spot for being that monumentally stupid. The cost ratio of an additional ~20GB of tape compared the enormous cost to the business if the server can't be restored quickly and reliably is staggering. Think $1 saved while risking millions of dollars of potential lost work! (1.6TB LTO5 tape = $80)
a) "what if you upgrade to a larger disk" -- there is no backup system on Earth that can't restore to bigger disks. Most systems can restore to smaller disks too. b) "what if the server is slower than others and people start moving their data to something" -- you back up both of them. Restoring too much is almost never as bad as restoring too little. c) "just blanket-backing-up is likely to lead to problems later on" -- no, it doesn't. Achieving 100% coverage ensures that no matter where you data was on a server (or which server), it's on a tape somewhere. d) "notifying IT of new things that need to be backed up" -- have you met humans? This never happens reliably, and can't ever be made reliable.
Back in the real world, a 100% complete backup of a typical Windows server can be restored without knowing the password, to dissimilar hardware (even virtual machines), and without needing the "original install disks". When it's done, it'll boot up, maybe reboot once or twice to fix up its drivers, and then your server is back, working as it did before. Compare that to a "data only" or partial backup. Now suddenly you're chasing down design documentation, passwords, IP addresses, software, serial numbers, and you haven't even started to restore anything yet. The clock is ticking, and the customer is breathing down your neck.
A week's work should take no more than two weeks at ABSOLUTE maximum to recreate
Recreate from what? Memory? Including data that was 100% electronic, and never seen by a human? How do you recreate your emails? How do you recreate your audit logs? How do you type back in non-textual data like digital images or audio recordings? How would you even know what's missing?
I'd rather have a decent monthly, than an imperfect daily
That's a false dichotomy. The total data stored is the same, you're just altering the frequency. The same amount of storage is needed, the same bandwidth is needed, and it ends up costing the same.
I'd rather have three backups a day than monthly backups. Losing a day of work could mean a contract fails to go through. I've been in a position twice now where users have come to me literally crying and begging to retrieve a document they only started working on that morning that they had deleted accidentally... at 8pm, minutes before a deadline for a multi million dollar deal. After experiences like those I've often set up incremental backup frequencies as rapid as 15 minutes.
So lets recap... your sum total DR experience is you once walked into a poorly supported environment, and gave them some even worse advice, without ever being in a position to be responsible for an actual real world recovery.
Well, take some advice from someone who's restored terabytes of data, and was responsible for the protection of over a petabyte spread across thousands of servers at over a dozen organisations:
#1 There are no time machines -- you cannot go back in time to fix a mistake in your backup strategy after a disaster. It's too late. You've fucked up, it's your fault, and you can never, ever, fix it.
#2 Back up everything -- I love genius IT folk who like to shave 1% off their backup times by excluding those useless temp and log files, also excluding 'useless junk' like their database transaction logs in the process.
Don't forget LLVM, which is probably more important than the rest of those put together.
It's set to potentially replace the back-end of GCC, Mono, GHC (Haskell), and probably a stack of other things. There's going to be a point in the near future where something like over half of the popular programming languages out there in the non-Windows world will be using an LLVM compiler back-end.
There's cameras on the buses and trains as well in Sydney. Cameras in taxi cabs are common in many countries.
Public transport attracts vandalism, theft, and other petty crimes, I'm sure the cameras help keep crime rates down. Cameras protect cabbies from abusive or criminal passengers, and passengers are protected against the same from the cab drivers. There have been incidents of sexual assault of young drunk girls by drivers, I'm sure they'd be less likely to try that sort of thing if there's a camera on board. Even if they can turn it off, that alone would be enough evidence of intent of wrongdoing for a conviction.
It's not like anybody is proposing that private vehicles will have cameras.
The Java version requires much more storage than you assume:
- arrays of objects aren't packed, they're arrays of pointers, so 1 pointer per entry - the actual AtomicStampedReference objects will require 2 pointers for each of its fields (the 'value' and the 'stamp') - the 'stamp' values are boxed, so they're independently allocated on the heap, probably taking at least 1 more pointer-sized memory allocation somewhere. - but looking at the source code shows that it's even worse than that, because it stores its data indirectly inside a private class held by a AtomicReference field. That adds at least 2 more pointers.
That's at least 6 words per entry.
In contrast, C# has value types (structures), so it can pack the "value" reference and the "stamp" into either 2 pointers, or 1.5 if you mix 64-bit pointers and 32-bit ints. In C#, arrays of value types are packed, so the total size is... 1.5-2 pointers per entry, just like in C. Unlike C, you'd end up spending 10x less time on all the other fiddly stuff by using a high-level language with a massive standard library, so you'd have more time to work on your algorithm.
That's just clearly wrong, so lets cleanse it with purifying fire.
But can't be used to represent characters, because Unicode requires at least 16 bits for the character type. So yeah... that's obvious.
No problem, I'll use wchar_t, which has a nice dependable size of... 8, 16, or 32 bits, and may be either signed or unsigned.
And btw in C you have intXX_t and uintXX_t types now.
Are you sure? They're in only present in recent versions of the standard library... and wait for it... while they're defined to be exactly XX bits, they're not guaranteed to exist.
Multi-threaded programming is particularly easy in those languages, because a lot of their internals are inherently thread-safe. For example, strings are read-only, so they can be passed around risk free. Similarly, mark & sweep garbage collection is thread-safe, and doesn't suffer from the rare but complex to debug memory leaks that occur with reference counting. It's also faster -- there's garbage collectors in common use now in the Java world that significantly outperform malloc. Throw in the overheads of atomic increment/decrement required for thread-safe reference counting in the C/C++ world, and suddenly things can tip towards Java in a big way.
I do C# mostly myself, and I've found that because it makes multi-threading so easy and safe (compared to C/C++), that I use it much more often than I would otherwise. Even if it's a tad slower than C, the ability to liberally sprinkle multi threading throughout the code makes the end result a lot more parallel, and hence overall faster or more responsive.
Take a look at the new await and async keywords about to be added to.NET v4.5. They allow traditional serial code to be converted to a thread-pooled asynchronous version with what amounts to about two dozen additonal characters of code!
Meanwhile, C and C++ have poor support for multi-threading, especially if code needs to be portable. There's basically no threading standard library to speak of, or even a threading aware memory model!
Sounds great, but all that nice sounding theory doesn't apply in practice. For example, C and C++ in particular are languages that started out "simple" but became quagmires over time. It's impossible to write portable C/C++ code that meets your requirements of "well structured and clean".
Haven't you noticed how every cross-platform C/C++ library starts out with pages of pages of "MY_LIBRARY_INT32" and "MY_LIBRARY_EXPORT" and other redefinitions of "standard" types, keywords, and functions? That's because C is a badly designed language where the behaviour and/or availability of even basic language keywords like "int" is a crap shoot that depends on the compiler and the target processor type. This then makes each library wonderfully unique and special, with their own macros to paper over this inconsistency.
Compare this to, say, C# or Java, where "int" is always exactly 32 bits and signed, no matter what. This means that if I pick up some random library off the web for some obscure purpose, it just works, and I'm don't have to figure out what the "int" type really means, or if it'll match the "int" type in some other library. I could go on about how every C library needs to redefine such basic concepts as memory allocation, or has a unique and special way of handling buffers or streams -- I'm sure you get the idea. No matter how skilled a programmer is, they will end up having to do the same kind of thing, because the language provides no real alternative, and the standard library is very small, and not very standard.
I recently had to pick up a C compression library, which had a simplified version for users who "didn't need all the fancy features of the full version". It had a 50KB header file, 99% of which platform-detection, followed by... five actual function definitions. Three of those were for memory management -- because everything needs that to be reinvented, clearly. How is this "clean"? What would you do to make this "clean", without dropping cross-platform support?
Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
public class Compressor {
public byte[] compress( byte[] data ) {... }
public byte[] decompress( byte[] data ) {... } }
A tad "cleaner" than 50KB of macros, don't you think?
On first execution (and compile) it's slow. On first creation of an instance it is slow.
But it doesn't have to be slow ever! Microsoft.NET doesn't have most of those problems, despite being otherwise mostly identical. That's because Microsoft applied this fantastic new technology that apparently Sun has never heard of called a "cache".
This is why Java fell flat on its face in the desktop world, because Sun couldn't wrap their heads around that fact that every launch will be a "first instance" because having dozens of simultaneously running instances of a single process is very rare on desktops. Oh, and of course, on top of this, Java doesn't share code between processes, so the few situations where there are many instances of a process running (e.g.: Citrix XenApp or Terminal Servers) can enjoy two to three times the memory usage compared to native and.NET applications.
Java was originally developed for set-top boxes where there's only one process running that starts on boot. It never really grew up to embrace the PC world, and works on servers as well as it does only coincidentally.
Every time there's an article in Slashdot about Firefox, there's at least one highly voted comment from someone complaining about Firefox being basically unmanageable on a corporate network.
I'm not talking about some massive effort to resolve complex issues like performance or memory, which have hundreds of subtle causes that have to be chased down and individually fixed. Creating an MSI requires simply an open source toolkit and a configuration file for the build process. For Active Directory Group Policy support, only a text file is needed and some minor tweaks to configuration parameter loading. The main installer doesn't even have to change! Just have an "enterprise downloads" section on the webpage.
The solution is simple and quick, it would massively increase the potential market for Firefox, but these feature requests will not be implemented. Not now, not ever, just no. The Firefox team doesn't do icky and boring technical stuff. Instead, they spend their valuable time on important things that clearly a lot of people need, like 3D graphics in the web browser.
Re:Yet another version, still no MSIs or GPOs
on
Firefox 8.0 Released
·
· Score: 1
But that's not shiny!
It's not... 3D in web pages... or... video decoding with JavaScript!
Those are sooooo much cooler to play with, I mean work on seriously like the professional developers we are.
Some years ago, I saw an organisation seriously consider rolling out Novell's SLED distro, which was their attempt at coming up with a desktop OS to compete with Windows in the enterprise space. It was simple to use, looked professional, it was supported, and most importantly: it looked a lot like Windows, so the transition for the 'average' corporate user wasn't too terrifying. It had lots of little things done well like a task bar on the bottom of the screen by default, a control panel with a layout similar to Windows, etc...
I looked at that, and thought: had they started work on this ten years ago, when they still had funds and top-notch engineers, a significant percentage of corporations would be running Linux desktops. Not 1% or whatever it is now, but more like 20% or even 40% of corporate desktops. Microsoft would have real competition, and that would be good for everyone, even the Windows users. As it was, SLED was too little, too late.
It's not too late to apply the concepts, but I fear that the problem is that open source developers aren't interested in it because this kind of work is boring, and in some ways an anathema to the typical Linux developer. Who wants to be a 'rebel' going against Microsoft's 'corporate greed' by copying their GUI exactly? Nobody! The users want something familiar, the developers want to be different. That's the problem!
I could see it happening if a decent sized corporation started paying full time developers to do it. It would be a lot of work, but Linux already had 90% of the technical requirements met, it just needs some polish to make it palatable as a desktop OS for the masses. I don't know about Canonical, but RedHat is probably big enough to do it.
To get there, all of the following must work, out-of-the-box, with no config file editing or installing optional stuff:
Joining Active Directory domains -- I don't mean some half-assed "Kerberos" support where the "domain" is a single IP address, I mean proper, 100% compliant domain member, with cross-domain and cross-forest auth, DNS SRV based service discovery, IPv6 support, TLS, SMB signing, the works. This should be as easy as it is in Windows: A GUI where I can enter the domain name and an administration credential, click OK, and that's it.
Windows-like GUI Behavior -- having the task bar on the bottom, a start menu with a search box, a "Run" start menu item, a control panel, and a GUI widget set with behaviours and keyboard shortcuts similar to Windows. The backspace button must always work, not just sometimes depending on how archaic the software is. Cut & paste with key presses only, not on highlight. Clicking a button does nothing if the mouse cursor moves off it before it is released (this behaviour inconsistent in Linux, consistent in Windows). Stuff like that. There's no need to actually copy the icons or the theme.
Unicode support everywhere -- and I mean everywhere: Every API (both user and kernel), the filesystem, user and group names, and even in the hidden stuff no user ever needs to see. Currently, much of Linux is stuck in the 8-bit world, and it's high time that people realised that not everyone speaks English!
Win32 compatibility -- someone should take WINE and make it a first-class citizen, so that Linux can run Windows applications just by double-clicking. People want to be able to pop in a CD, click setup.exe, and just have it work. This is 90% of the value that Microsoft provides their enterprise customers: compatibility with about a trillion dollars worth of software that's been developed over the last two decades. WINE is currently focused on compatibility with a bunch of... games. Not quite the same value proposition! Will my Win32 exe work on Linux with the Oracle client? Will it talk to SharePoint with Kerberos single-sign-on? Probably not.
Group Policy -- Lockdown and central control over desktop environments are alien concepts to
I was thinking renderfarm myself, but a) that's 90% about the floating point performance, not integer, and ARM isn't stellar on floating point throughput, and b) a lot of scenes these days are greater than 4GB. While it may be possible to "tile" some scenes, the most compute expensive bit (that you'd want to accelerate the most) is global illumination, which basically needs the whole scene in RAM.
Being forced to stay under some arbitrary scene complexity limit would suck, especially with tools like ZBrush that can generate billion-polygon models.
Those processors run at only about 1.1 GHz, and ARM isn't quite as snappy on a "per GHz" basis as a typical Intel core because of the power-vs-speed tradeoff, so I figure that a 1.1 GHz ARM quad-core chip has about the same computer power as a single ~3GHz latest generation Intel Xeon core.
They say the can pack 288 quad core ARM processors into 4 rack units (with no disks). For comparison, HP sells blade systems that let you pack in 16 dual-socket blades into 10 rack units. Populate each socket with a 10 core Intel Xeon, and we're talking 320 cores. So for comparison, that's the equivalent of 72 cores per rack unit with ARM, vs 32 with Intel. The memory density is the other way around, with 288 GB per rack unit for ARM, and 614 GB with Intel.
So, if you have a an embarrassingly parallel problem to solve that can fit into 4GB of memory per node, doesn't use much I/O, and can run on Linux, this might be a pretty good idea.
Lets so how non-Windows we can get. There's VMware ESXi, the bare-metal hypervisor that's not even a POSIX operating system. It has PowerShell support. So does Citrix XenServer, which is Linux/Xen based. (So does Microsoft Hyper-V, of course, but that doesn't count as non-Windows). That's just off the top of my head. Not that it matters, because Windows PowerShell is not surprisingly, a Windows technology. No Windows administrator cares that their Windows automation scripts don't run on their Solaris boxes.
Anyway, bash scripts aren't cross-platform either. I mean, sure, the actual bash interpreter is written in just POSIX C and can be ported to anything (I've used it on Windows myself), but that's useless with the external commands. ALL OF WHICH ARE DIFFERENT, even on one platform! Have you seen the horror that is a truly "cross-platform" script? It begins with pages and pages of if-else statements to figure out what's what, and how stuff works. Then there's ten lines of actual script.
Sure, they're vaguely similar, and have a bunch of options in common, but that's where it ends. Formatting is all different. Filtering has different capabilities. I bet the output is different also.
So put or up shut up. Write me a script, quickly (and I stress that word for a reason -- time is money), to do exactly the following task, across a bunch of different unixes:
Output all processes with the name "bash" into an RFC 4180 compliant comma separated values (CSV) file. Do not include extraneous processes. Don't forget the header. Make sure quotes and spaces are correctly handled. Ensure Unicode is handled on platforms that support it (e.g.: Solaris). Make sure numbers are formatted consistently, irrespective of the operating system regional options. Ensure that every platform outputs exactly the same columns, in the same order. Have it work on, at a minimum: AIX, Solaris, HP-UX, OpenBSD, and Linux. Your time starts now... go!
It's very, VERY hard. So difficult that you failed to solve the rather trivial problems I gave. You gave me something that is incomplete, and does something only vaguely similar, yet is still complex and wrong.
I didn't say "export to some random text file", I said, "comma separated values" (CSV) file -- something I can double-click and open in Excel without problems. I want commands for a CSV file from both data sources, not just one, because I want you to sit down and figure out it, and realise that you'll end up with two very different solutions, even thought the problem description is nearly identical: get some data, format it.
Your SSH command is for one machine only, and doesn't include the machine name in the output as a column. Sure, it vaguely does what I said, but what I want to do is compare the CPU times of processes across my farm of servers using Excel. Does you solution do that? No.
Your "awk" version is even more complex, doesn't include proper column headers, and won't escape quote characters correctly.
Notice how "ps" has like... a bazillion options? What the fuck is "-ef"? I had to look it up. It's "show every process" in "full format". Err... obviously. What exactly is "full format"? Who knows! It's... something fuller than not-full format, clearly. It has it's own sort syntax, different to the sort syntax of other commands. It outputs tabular data, but god only knows in what format exactly. It certainly doesn't have the same output format as any other command. Notice how the exact same option to "service" is not "-ef", but "--status-all". Does "service" have a "sort" option? Nope.
Meanwhile, in Windows land: Sort-Object (or just "sort") works on the output of every command exactly the same way. The Format-Table" and Format-List commands work, again, exactly the same on the output of every command. There's no need for pages of cryptic options for such a basic command as "ps". Take a look at the list of options for Get-Process. Not counting common parameters, it has a grand total of just six! In comparison, ps has over 50, and the list depends on the platform.
I mean, for God's sake, even just this bit: "ps -ef |grep bash" has a subtle error in it. What happens if a user's account name contains the character string "bash?" As in, say, BobAshfield or something? You get unexpected, spurious output. This is what happens when you blindly use string processing to perform database-like functionality. You have a table of data that you want to filter by a column. Why do a text-search instead? What you meant was:
Get-Process | Where-Object { $_.Name -eq 'bash' }
Or more elegantly:
Get-Process -Name 'bash'
But there's an alias for Get-Process (ps), and the "name" is the default... so:
ps bash
will work, if you must save those precious keystrokes.
But why would you? Everything tab-completes in PowerShell, even the parameter names.
Have you used it recently? PowerShell is far more capable and user friendly than anything on Linux, and Microsoft is throwing their full weight behind it. In Windows 8, it will have modules for basically everything, and a Windows administrator will be able to script circles around anyone still using archaic shells like Bash.
Every time I hear someone talk about the real-world benefits of Linux, the command-line is often near the top, but that's about to vanish. Microsoft, whatever their faults, has huge manpower available to implement things in a consistent, documented, integrated way, and now that they have an elegant framework for a command-line shell, they're going to throw a ton of weight behind it. In Windows 8, the number of PS modules has gone from less than a dozen to over 200!
Explain to me again what is so superior about Linux's command-line?
Better yet, I'll give you a simple challenge: As fast as you can, list for me the command-lines to perform the following three tasks in a robust way:
- Generate a CSV export of all running processes, including performance statistics - Generate a CSV report of all services, including status (stopped, running, paused, etc...) - For each of the above, do the same, but generate a combined report across many computers listed by name in a text file. Include the computer name as a column in the output.
I'll give you the one-line PowerShell solution to one of the last ones for comparison:
Too verbose for your taste? The complete solution in PowerShell is just the following four lines:
gsv | epcsv services.txt
ps | epcsv processes.txt
gsv -cn ( gc servers.txt ) | epcsv remote_services.txt
ps -cn ( gc servers.txt ) | epcsv remote_processes.txt
In short, film is and will continue to be the ONLY technology proof way of storing information. That digital media is volatile, degrades badly over time (less than a decade) and requires constant electrical supply as well as constant upgrades of gear (decade or less).
I'm not sure if all of you analog archivists are just very clever trolls, but in case you were actually serious:
"film is and will continue to be the ONLY technology proof way of storing information" - false, there's lots of other ways, film is actually quite bad at storing information -- you said it yourself: "Sometimes the film is perfectly usable. Sometimes it's dust.". How is that a good thing?
"digital media is volatile" -- not it's not. It won't evaporate, or vanish. If you mean "likely to change suddenly", it's not even that, because the whole point of something being digital is that it doesn't change over time. In contrast, every analog format changes constantly, no matter what you do.
"degrades badly over time (less than a decade)" -- that's not true either, in any sense. Fist of all, a well kept digital copy doesn't degrade at all, as in, not a single bit of information wrong. Archival quality WORM optical disks will last a lot longer than a decade, but anyone with some common sense would just keep multiple copies instead and copy data onto new generation storage every few years. And here's the thing: if you have multiple digital copies, it's trivial to reconstruct a flawless original copy, unlike archived films that look horrible despite careful restoration. Even a single copy can be made very robust using error correcting codes.
"requires constant electrical supply" -- are you keeping your "archival data" in RAM? Seriously? No digital media of any kind will lose data without power. Many archives use optical disks, which can be read with equipment that could be powered by a stationary bicycle. I think you're overestimating the robustness requirements for archives. If you can't power the archive reader because nobody has enough power for it anywhere, the human race has much bigger problems than immediate access to a 100 year old film -- which nobody would be able to project anyway without electrical lighting. Get a grip.
"constant upgrades of gear" -- which is actually a benefit. With analog, you can't upgrade your gear, whereas with digital, the archives that used to take up a whole building will eventually neatly fit into something the size of a thumbnail. The cost of preservation will drop to pennies instead of millions of dollars. Keeping dozens or even thousands of redundant copies will become easy. With analog, nothing like that will ever happen. A roll of film will continue to take up exactly the same amount of shelfspace it always did.
One estimate is that the US Library of Congress has about 300 TB of accumulated archival data. This is just 100x 3TB hard drives. That's a pile of drives about the size of a small suitecase that would cost under $20K. Now stop and think for a minute... the entire LoC, in your room, for $20K. Seagate has just announced a 4TB hard drive. Manufacturers are developing patterned media and hybrid laser/magnetic storage. Rumors are that 10TB will be doable. Do you see a pattern emerging? How long do you think it'll be before you can just have the entire library of congress on a single drive, in the palm of your hand? Not robust enough for you? Buy two! Or two dozen! Every year! It'll cost less than what the LoC spends on coffee for their staff!
Let me rephrase that for you:...I want to be able to hear the nuclear engineer talk about what it was like to be inside the reactor, shrug off the risk, and feel proud that someday people will go where I would never have dared. Robots have their place to prepare the areas to live and all that, but there is no substitute for actual people.
It sounds stupid, but it's directly comparable. Space is full of deadly, ionising radiation, and that is actually the least of the hazards! How is it a good thing to send someone into that environment needlessly, when there are robots available to do it? Should we decommission the robots used in nuclear engineering so that the brave engineers' widows can be proud of their noble sacrifice?
Every time some science fiction fan like you gets all dreamy about space colonisation, ignoring the harsh realities glossed over in fiction, I like to give this challenge:
If you think it's so fantastic living isolated from the rest of humanity on a cold rock in a hard vacuum, and that you'd just "jump" at the opportunity, then move to Bouvet Island, with the following rules: you have to carry everything you'll ever need with you (including air), delay radio communications by ten minutes, have a one year delay on any visits or assistance, the building at the destination has to be airtight, and you never get to leave it unless dressed in a head-to-toe scuba gear. Also, for every pound of material you take with you, donate $100 to your favourite charity. For extra realism, sprinkle some radioactive material around your dwelling and take medication that causes osteoporosis.
All the fun of space, for a fraction of the cost, and you can do it right now! Why delay?
The James Webb Space Telescope is going to cost about 10 Billion by itself, and it's just a single-rocket unmanned mission that doesn't go anywhere near as far as Mars!
NASA's yearly budget is already over 15 Billion. It's a safe bet that a mission to the Moon or Mars would take at least a decade, and NASA's budget would have to double at a minimum. That's a 150 Billion right there, as a lower bound. More realistically, like you said, NASA's budget would have to increase manyfold, and mission would take longer. That implies a cost of over a trillion dollars.
Note that this isn't like the bailout, which were loans that were eventually repaid. This is a trillion dollars that are going to be launched into space, never to come back.
Slashdot Mirror
Right, because the government's will trumps any sort of idea that you can make choices for you or your children.
The government merely represents society, and their will is that you can't make choices for other people's children.
Un-immunised children put everyone at risk.
It will BSOD on boot, yes, but there is a standard, supported, and reliable way of fixing it. It's called an in-place upgrade install mode, which is the second repair option when booting the 2000/XP/2003 install CDs.
Basically, you "upgrade" Windows to the same version. What this does is it re-detects all hardware configuration, including storage, but leaves the software configuration unchanged. It can be used to move from non-ACPI to ACPI, change the HAL, fix storage drivers, and a bunch of other things. The downside is that hotfixes and IP settings are lost, so it takes a bit more work afterwards -- the server has to be patched and reconfigured a little bit.
These days, I tend to restore Windows servers to virtual machines, out-of-place. As you mentioned, it provides the opportunity to simplify the drivers, and it's possible to take a snapshot immediately after the restore. That way, if any post-restore repair steps fail or corrupt the system, I don't have to start the restore from the beginning. That does wonders for things like Exchange server restores. One of the most successful DR jobs I've done was to recover a ~250GB Exchange database to an ESX server. I cloned it out four times using thin-cloning, which takes just seconds, and then tried four different database repair methods in parallel. It was doing 60K IOPS sustained! 8)
I've had similar experience, but I've found that it swings back toward disk in a big way on the low-end. If you can fit your data onto a single 2TB disk, then it's much more reliable than tape, and cheaper too.
Tape is also a lot less reliable outside data centres, because practically nobody designs those drives to survive the dust in a typical office environment. I've seen about 50% or more of the tape systems out in the field fail at least once a year, but I've never seen a disk based backup system fail. Note once, not ever.
Also, tapes aren't as robust as people think they are. One of the hardest IT troubleshooting jobs I've ever worked on was a tape system that had regular failures. Turned out that the IT guy liked to throw the tapes up in the air (only about a foot or two), and then catch them. He didn't drop them or anything, but that was enough to cause regular backup failures. That's less robust than a (powered off) disk drive.
I've got a feeling that tape reliability numbers are massively exaggerated in marketing materials. For example, I once had a tape getting repeatedly loaded, read a little bit, and then unloaded overnight because of a software bug. It was destroyed. Think grooves etched into the plastic casing, and the tape worn to the point of transparency. That got me thinking, and I looked up the numbers.
People get confused by numbers like "1,000,000 passes" in the specifications. You have to read the full version: "1,000,000 passes on any area of tape, equates to over 20,000 end to end passes/260 full tape backups". People forget that LTO makes many passes per backup, so suddenly you're down to a three digit number of backups instead of the huge sounding million they start with in the brochure. Throw in verify-after-backup, and it's only 130. If you back up daily, that's just over four months before your tapes are worn out, according to the spec. Meanwhile, even consumer grade hard drives can last for years, even decades.
I hope you're a troll, because if you're not, this is just about the most insanely fucked up attitude to data protection I've ever seen.
A blind "Let's just backup the whole server" isn't an effective backup strategy ...
If I was your boss I'd fire you on the spot for being that monumentally stupid. The cost ratio of an additional ~20GB of tape compared the enormous cost to the business if the server can't be restored quickly and reliably is staggering. Think $1 saved while risking millions of dollars of potential lost work! (1.6TB LTO5 tape = $80)
a) "what if you upgrade to a larger disk" -- there is no backup system on Earth that can't restore to bigger disks. Most systems can restore to smaller disks too.
b) "what if the server is slower than others and people start moving their data to something" -- you back up both of them. Restoring too much is almost never as bad as restoring too little.
c) "just blanket-backing-up is likely to lead to problems later on" -- no, it doesn't. Achieving 100% coverage ensures that no matter where you data was on a server (or which server), it's on a tape somewhere.
d) "notifying IT of new things that need to be backed up" -- have you met humans? This never happens reliably, and can't ever be made reliable.
Back in the real world, a 100% complete backup of a typical Windows server can be restored without knowing the password, to dissimilar hardware (even virtual machines), and without needing the "original install disks". When it's done, it'll boot up, maybe reboot once or twice to fix up its drivers, and then your server is back, working as it did before. Compare that to a "data only" or partial backup. Now suddenly you're chasing down design documentation, passwords, IP addresses, software, serial numbers, and you haven't even started to restore anything yet. The clock is ticking, and the customer is breathing down your neck.
A week's work should take no more than two weeks at ABSOLUTE maximum to recreate
Recreate from what? Memory? Including data that was 100% electronic, and never seen by a human? How do you recreate your emails? How do you recreate your audit logs? How do you type back in non-textual data like digital images or audio recordings? How would you even know what's missing?
I'd rather have a decent monthly, than an imperfect daily
That's a false dichotomy. The total data stored is the same, you're just altering the frequency. The same amount of storage is needed, the same bandwidth is needed, and it ends up costing the same.
I'd rather have three backups a day than monthly backups. Losing a day of work could mean a contract fails to go through. I've been in a position twice now where users have come to me literally crying and begging to retrieve a document they only started working on that morning that they had deleted accidentally... at 8pm, minutes before a deadline for a multi million dollar deal. After experiences like those I've often set up incremental backup frequencies as rapid as 15 minutes.
So lets recap... your sum total DR experience is you once walked into a poorly supported environment, and gave them some even worse advice, without ever being in a position to be responsible for an actual real world recovery.
Well, take some advice from someone who's restored terabytes of data, and was responsible for the protection of over a petabyte spread across thousands of servers at over a dozen organisations:
#1 There are no time machines -- you cannot go back in time to fix a mistake in your backup strategy after a disaster. It's too late. You've fucked up, it's your fault, and you can never, ever, fix it.
#2 Back up everything -- I love genius IT folk who like to shave 1% off their backup times by excluding those useless temp and log files, also excluding 'useless junk' like their database transaction logs in the process.
Don't forget LLVM, which is probably more important than the rest of those put together.
It's set to potentially replace the back-end of GCC, Mono, GHC (Haskell), and probably a stack of other things. There's going to be a point in the near future where something like over half of the popular programming languages out there in the non-Windows world will be using an LLVM compiler back-end.
There's cameras on the buses and trains as well in Sydney. Cameras in taxi cabs are common in many countries.
Public transport attracts vandalism, theft, and other petty crimes, I'm sure the cameras help keep crime rates down. Cameras protect cabbies from abusive or criminal passengers, and passengers are protected against the same from the cab drivers. There have been incidents of sexual assault of young drunk girls by drivers, I'm sure they'd be less likely to try that sort of thing if there's a camera on board. Even if they can turn it off, that alone would be enough evidence of intent of wrongdoing for a conviction.
It's not like anybody is proposing that private vehicles will have cameras.
What's everyone getting so upset about?
Oh, and .NET can DIAF.
The Java version requires much more storage than you assume:
- arrays of objects aren't packed, they're arrays of pointers, so 1 pointer per entry
- the actual AtomicStampedReference objects will require 2 pointers for each of its fields (the 'value' and the 'stamp')
- the 'stamp' values are boxed, so they're independently allocated on the heap, probably taking at least 1 more pointer-sized memory allocation somewhere.
- but looking at the source code shows that it's even worse than that, because it stores its data indirectly inside a private class held by a AtomicReference field. That adds at least 2 more pointers.
That's at least 6 words per entry.
In contrast, C# has value types (structures), so it can pack the "value" reference and the "stamp" into either 2 pointers, or 1.5 if you mix 64-bit pointers and 32-bit ints. In C#, arrays of value types are packed, so the total size is... 1.5-2 pointers per entry, just like in C. Unlike C, you'd end up spending 10x less time on all the other fiddly stuff by using a high-level language with a massive standard library, so you'd have more time to work on your algorithm.
That's just clearly wrong, so lets cleanse it with purifying fire.
"char" is probably the most stable type in C
But can't be used to represent characters, because Unicode requires at least 16 bits for the character type. So yeah... that's obvious.
No problem, I'll use wchar_t, which has a nice dependable size of... 8, 16, or 32 bits, and may be either signed or unsigned.
And btw in C you have intXX_t and uintXX_t types now.
Are you sure? They're in only present in recent versions of the standard library... and wait for it... while they're defined to be exactly XX bits, they're not guaranteed to exist.
C# and Java both have atomic operations in the standard library. See Interlocked.CompareExchange, and java.util.concurrent.atomic for examples.
Multi-threaded programming is particularly easy in those languages, because a lot of their internals are inherently thread-safe. For example, strings are read-only, so they can be passed around risk free. Similarly, mark & sweep garbage collection is thread-safe, and doesn't suffer from the rare but complex to debug memory leaks that occur with reference counting. It's also faster -- there's garbage collectors in common use now in the Java world that significantly outperform malloc. Throw in the overheads of atomic increment/decrement required for thread-safe reference counting in the C/C++ world, and suddenly things can tip towards Java in a big way.
I do C# mostly myself, and I've found that because it makes multi-threading so easy and safe (compared to C/C++), that I use it much more often than I would otherwise. Even if it's a tad slower than C, the ability to liberally sprinkle multi threading throughout the code makes the end result a lot more parallel, and hence overall faster or more responsive.
Take a look at the new await and async keywords about to be added to .NET v4.5. They allow traditional serial code to be converted to a thread-pooled asynchronous version with what amounts to about two dozen additonal characters of code!
Meanwhile, C and C++ have poor support for multi-threading, especially if code needs to be portable. There's basically no threading standard library to speak of, or even a threading aware memory model!
O_o
Oh my god! This is why I'm not ever going back to C/C++ unless forced to at gunpoint.
Sounds great, but all that nice sounding theory doesn't apply in practice. For example, C and C++ in particular are languages that started out "simple" but became quagmires over time. It's impossible to write portable C/C++ code that meets your requirements of "well structured and clean".
Haven't you noticed how every cross-platform C/C++ library starts out with pages of pages of "MY_LIBRARY_INT32" and "MY_LIBRARY_EXPORT" and other redefinitions of "standard" types, keywords, and functions? That's because C is a badly designed language where the behaviour and/or availability of even basic language keywords like "int" is a crap shoot that depends on the compiler and the target processor type. This then makes each library wonderfully unique and special, with their own macros to paper over this inconsistency.
Compare this to, say, C# or Java, where "int" is always exactly 32 bits and signed, no matter what. This means that if I pick up some random library off the web for some obscure purpose, it just works, and I'm don't have to figure out what the "int" type really means, or if it'll match the "int" type in some other library. I could go on about how every C library needs to redefine such basic concepts as memory allocation, or has a unique and special way of handling buffers or streams -- I'm sure you get the idea. No matter how skilled a programmer is, they will end up having to do the same kind of thing, because the language provides no real alternative, and the standard library is very small, and not very standard.
I recently had to pick up a C compression library, which had a simplified version for users who "didn't need all the fancy features of the full version". It had a 50KB header file, 99% of which platform-detection, followed by... five actual function definitions. Three of those were for memory management -- because everything needs that to be reinvented, clearly. How is this "clean"? What would you do to make this "clean", without dropping cross-platform support?
Meanwhile, this Java code will work on all platforms, processors, and compilers, forever and ever:
public class Compressor { ... } ... }
public byte[] compress( byte[] data ) {
public byte[] decompress( byte[] data ) {
}
A tad "cleaner" than 50KB of macros, don't you think?
On first execution (and compile) it's slow. On first creation of an instance it is slow.
But it doesn't have to be slow ever! Microsoft .NET doesn't have most of those problems, despite being otherwise mostly identical. That's because Microsoft applied this fantastic new technology that apparently Sun has never heard of called a "cache".
This is why Java fell flat on its face in the desktop world, because Sun couldn't wrap their heads around that fact that every launch will be a "first instance" because having dozens of simultaneously running instances of a single process is very rare on desktops. Oh, and of course, on top of this, Java doesn't share code between processes, so the few situations where there are many instances of a process running (e.g.: Citrix XenApp or Terminal Servers) can enjoy two to three times the memory usage compared to native and .NET applications.
Java was originally developed for set-top boxes where there's only one process running that starts on boot. It never really grew up to embrace the PC world, and works on servers as well as it does only coincidentally.
Oh I don't know, how about ignoring the need for MSI installers and Group Policy support for seven fucking years?
Every time there's an article in Slashdot about Firefox, there's at least one highly voted comment from someone complaining about Firefox being basically unmanageable on a corporate network.
I'm not talking about some massive effort to resolve complex issues like performance or memory, which have hundreds of subtle causes that have to be chased down and individually fixed. Creating an MSI requires simply an open source toolkit and a configuration file for the build process. For Active Directory Group Policy support, only a text file is needed and some minor tweaks to configuration parameter loading. The main installer doesn't even have to change! Just have an "enterprise downloads" section on the webpage.
The solution is simple and quick, it would massively increase the potential market for Firefox, but these feature requests will not be implemented. Not now, not ever, just no. The Firefox team doesn't do icky and boring technical stuff. Instead, they spend their valuable time on important things that clearly a lot of people need, like 3D graphics in the web browser.
But that's not shiny!
It's not... 3D in web pages... or... video decoding with JavaScript!
Those are sooooo much cooler to play with, I mean work on seriously like the professional developers we are.
I've actually put some thought into this.
Some years ago, I saw an organisation seriously consider rolling out Novell's SLED distro, which was their attempt at coming up with a desktop OS to compete with Windows in the enterprise space. It was simple to use, looked professional, it was supported, and most importantly: it looked a lot like Windows, so the transition for the 'average' corporate user wasn't too terrifying. It had lots of little things done well like a task bar on the bottom of the screen by default, a control panel with a layout similar to Windows, etc...
I looked at that, and thought: had they started work on this ten years ago, when they still had funds and top-notch engineers, a significant percentage of corporations would be running Linux desktops. Not 1% or whatever it is now, but more like 20% or even 40% of corporate desktops. Microsoft would have real competition, and that would be good for everyone, even the Windows users. As it was, SLED was too little, too late.
It's not too late to apply the concepts, but I fear that the problem is that open source developers aren't interested in it because this kind of work is boring, and in some ways an anathema to the typical Linux developer. Who wants to be a 'rebel' going against Microsoft's 'corporate greed' by copying their GUI exactly? Nobody! The users want something familiar, the developers want to be different. That's the problem!
I could see it happening if a decent sized corporation started paying full time developers to do it. It would be a lot of work, but Linux already had 90% of the technical requirements met, it just needs some polish to make it palatable as a desktop OS for the masses. I don't know about Canonical, but RedHat is probably big enough to do it.
To get there, all of the following must work, out-of-the-box, with no config file editing or installing optional stuff:
Joining Active Directory domains -- I don't mean some half-assed "Kerberos" support where the "domain" is a single IP address, I mean proper, 100% compliant domain member, with cross-domain and cross-forest auth, DNS SRV based service discovery, IPv6 support, TLS, SMB signing, the works. This should be as easy as it is in Windows: A GUI where I can enter the domain name and an administration credential, click OK, and that's it.
Windows-like GUI Behavior -- having the task bar on the bottom, a start menu with a search box, a "Run" start menu item, a control panel, and a GUI widget set with behaviours and keyboard shortcuts similar to Windows. The backspace button must always work, not just sometimes depending on how archaic the software is. Cut & paste with key presses only, not on highlight. Clicking a button does nothing if the mouse cursor moves off it before it is released (this behaviour inconsistent in Linux, consistent in Windows). Stuff like that. There's no need to actually copy the icons or the theme.
Unicode support everywhere -- and I mean everywhere: Every API (both user and kernel), the filesystem, user and group names, and even in the hidden stuff no user ever needs to see. Currently, much of Linux is stuck in the 8-bit world, and it's high time that people realised that not everyone speaks English!
Win32 compatibility -- someone should take WINE and make it a first-class citizen, so that Linux can run Windows applications just by double-clicking. People want to be able to pop in a CD, click setup.exe, and just have it work. This is 90% of the value that Microsoft provides their enterprise customers: compatibility with about a trillion dollars worth of software that's been developed over the last two decades. WINE is currently focused on compatibility with a bunch of... games. Not quite the same value proposition! Will my Win32 exe work on Linux with the Oracle client? Will it talk to SharePoint with Kerberos single-sign-on? Probably not.
Group Policy -- Lockdown and central control over desktop environments are alien concepts to
You'd be surprised!
Google Code search allows regex matching, e.g.: [abc]+foo.
Go to a course that teaches them that "client-side security is no security at all" over and over until it sinks in?
I was thinking renderfarm myself, but a) that's 90% about the floating point performance, not integer, and ARM isn't stellar on floating point throughput, and b) a lot of scenes these days are greater than 4GB. While it may be possible to "tile" some scenes, the most compute expensive bit (that you'd want to accelerate the most) is global illumination, which basically needs the whole scene in RAM.
Being forced to stay under some arbitrary scene complexity limit would suck, especially with tools like ZBrush that can generate billion-polygon models.
Those processors run at only about 1.1 GHz, and ARM isn't quite as snappy on a "per GHz" basis as a typical Intel core because of the power-vs-speed tradeoff, so I figure that a 1.1 GHz ARM quad-core chip has about the same computer power as a single ~3GHz latest generation Intel Xeon core.
They say the can pack 288 quad core ARM processors into 4 rack units (with no disks). For comparison, HP sells blade systems that let you pack in 16 dual-socket blades into 10 rack units. Populate each socket with a 10 core Intel Xeon, and we're talking 320 cores. So for comparison, that's the equivalent of 72 cores per rack unit with ARM, vs 32 with Intel. The memory density is the other way around, with 288 GB per rack unit for ARM, and 614 GB with Intel.
So, if you have a an embarrassingly parallel problem to solve that can fit into 4GB of memory per node, doesn't use much I/O, and can run on Linux, this might be a pretty good idea.
Lets so how non-Windows we can get. There's VMware ESXi, the bare-metal hypervisor that's not even a POSIX operating system. It has PowerShell support. So does Citrix XenServer, which is Linux/Xen based. (So does Microsoft Hyper-V, of course, but that doesn't count as non-Windows). That's just off the top of my head. Not that it matters, because Windows PowerShell is not surprisingly, a Windows technology. No Windows administrator cares that their Windows automation scripts don't run on their Solaris boxes.
Anyway, bash scripts aren't cross-platform either. I mean, sure, the actual bash interpreter is written in just POSIX C and can be ported to anything (I've used it on Windows myself), but that's useless with the external commands. ALL OF WHICH ARE DIFFERENT, even on one platform! Have you seen the horror that is a truly "cross-platform" script? It begins with pages and pages of if-else statements to figure out what's what, and how stuff works. Then there's ten lines of actual script.
Here's a random example from a script found with this google search:
elif [ "$os" = "OpenBSD" ] ; then :" /etc/passwd.conf
$echo "/etc/passwd.conf
egrep -v "$comments"
elif [ "$os" = "HP-UX" ] ; then :" /etc/pam.conf
$echo "/etc/pam.conf
egrep -v "$comments"
else :" /etc/pam.d/passwd
$echo "/etc/pam.d/passwd
egrep -v "$comments"
fi
if [ "$os" = "Linux" ] ; then
$echo "pwck -l"
pwck -r
grpck -r
fi
Cross platform my ass.
Anyway, lets go back to our earlier, trivial example: "ps"
Here's two google hits: Linux, and Solaris.
Sure, they're vaguely similar, and have a bunch of options in common, but that's where it ends. Formatting is all different. Filtering has different capabilities. I bet the output is different also.
So put or up shut up. Write me a script, quickly (and I stress that word for a reason -- time is money), to do exactly the following task, across a bunch of different unixes:
Output all processes with the name "bash" into an RFC 4180 compliant comma separated values (CSV) file. Do not include extraneous processes. Don't forget the header. Make sure quotes and spaces are correctly handled. Ensure Unicode is handled on platforms that support it (e.g.: Solaris). Make sure numbers are formatted consistently, irrespective of the operating system regional options. Ensure that every platform outputs exactly the same columns, in the same order. Have it work on, at a minimum: AIX, Solaris, HP-UX, OpenBSD, and Linux. Your time starts now... go!
Doing stuff on a *nix system is not hard...
It's very, VERY hard. So difficult that you failed to solve the rather trivial problems I gave. You gave me something that is incomplete, and does something only vaguely similar, yet is still complex and wrong.
I didn't say "export to some random text file", I said, "comma separated values" (CSV) file -- something I can double-click and open in Excel without problems. I want commands for a CSV file from both data sources, not just one, because I want you to sit down and figure out it, and realise that you'll end up with two very different solutions, even thought the problem description is nearly identical: get some data, format it.
Your SSH command is for one machine only, and doesn't include the machine name in the output as a column. Sure, it vaguely does what I said, but what I want to do is compare the CPU times of processes across my farm of servers using Excel. Does you solution do that? No.
Your "awk" version is even more complex, doesn't include proper column headers, and won't escape quote characters correctly.
Notice how "ps" has like... a bazillion options? What the fuck is "-ef"? I had to look it up. It's "show every process" in "full format". Err... obviously. What exactly is "full format"? Who knows! It's... something fuller than not-full format, clearly. It has it's own sort syntax, different to the sort syntax of other commands. It outputs tabular data, but god only knows in what format exactly. It certainly doesn't have the same output format as any other command. Notice how the exact same option to "service" is not "-ef", but "--status-all". Does "service" have a "sort" option? Nope.
Meanwhile, in Windows land: Sort-Object (or just "sort") works on the output of every command exactly the same way. The Format-Table" and Format-List commands work, again, exactly the same on the output of every command. There's no need for pages of cryptic options for such a basic command as "ps". Take a look at the list of options for Get-Process. Not counting common parameters, it has a grand total of just six! In comparison, ps has over 50, and the list depends on the platform.
I mean, for God's sake, even just this bit: "ps -ef |grep bash" has a subtle error in it. What happens if a user's account name contains the character string "bash?" As in, say, BobAshfield or something? You get unexpected, spurious output. This is what happens when you blindly use string processing to perform database-like functionality. You have a table of data that you want to filter by a column. Why do a text-search instead? What you meant was:
Get-Process | Where-Object { $_.Name -eq 'bash' }
Or more elegantly:
Get-Process -Name 'bash'
But there's an alias for Get-Process (ps), and the "name" is the default... so:
ps bash
will work, if you must save those precious keystrokes.
But why would you? Everything tab-completes in PowerShell, even the parameter names.
On windows the CLI is useless
Have you used it recently? PowerShell is far more capable and user friendly than anything on Linux, and Microsoft is throwing their full weight behind it. In Windows 8, it will have modules for basically everything, and a Windows administrator will be able to script circles around anyone still using archaic shells like Bash.
Every time I hear someone talk about the real-world benefits of Linux, the command-line is often near the top, but that's about to vanish. Microsoft, whatever their faults, has huge manpower available to implement things in a consistent, documented, integrated way, and now that they have an elegant framework for a command-line shell, they're going to throw a ton of weight behind it. In Windows 8, the number of PS modules has gone from less than a dozen to over 200!
Even PowerShell 2 already ships with an integrated GUI IDE and visual debugger, a command-line debugger, a tracing utility, secure remote shell, and a job system. It's user friendly and can be trivially extended with C# or VB.NET, which can be developed with free GUI IDEs!
Explain to me again what is so superior about Linux's command-line?
Better yet, I'll give you a simple challenge: As fast as you can, list for me the command-lines to perform the following three tasks in a robust way:
- Generate a CSV export of all running processes, including performance statistics
- Generate a CSV report of all services, including status (stopped, running, paused, etc...)
- For each of the above, do the same, but generate a combined report across many computers listed by name in a text file. Include the computer name as a column in the output.
I'll give you the one-line PowerShell solution to one of the last ones for comparison:
Get-Process -ComputerName ( Get-Content servers.txt ) | Export-CSV processes.txt
Too verbose for your taste? The complete solution in PowerShell is just the following four lines:
gsv | epcsv services.txt
ps | epcsv processes.txt
gsv -cn ( gc servers.txt ) | epcsv remote_services.txt
ps -cn ( gc servers.txt ) | epcsv remote_processes.txt
In short, film is and will continue to be the ONLY technology proof way of storing information. That digital media is volatile, degrades badly over time (less than a decade) and requires constant electrical supply as well as constant upgrades of gear (decade or less).
I'm not sure if all of you analog archivists are just very clever trolls, but in case you were actually serious:
"film is and will continue to be the ONLY technology proof way of storing information" - false, there's lots of other ways, film is actually quite bad at storing information -- you said it yourself: "Sometimes the film is perfectly usable. Sometimes it's dust.". How is that a good thing?
"digital media is volatile" -- not it's not. It won't evaporate, or vanish. If you mean "likely to change suddenly", it's not even that, because the whole point of something being digital is that it doesn't change over time. In contrast, every analog format changes constantly, no matter what you do.
"degrades badly over time (less than a decade)" -- that's not true either, in any sense. Fist of all, a well kept digital copy doesn't degrade at all, as in, not a single bit of information wrong. Archival quality WORM optical disks will last a lot longer than a decade, but anyone with some common sense would just keep multiple copies instead and copy data onto new generation storage every few years. And here's the thing: if you have multiple digital copies, it's trivial to reconstruct a flawless original copy, unlike archived films that look horrible despite careful restoration. Even a single copy can be made very robust using error correcting codes.
"requires constant electrical supply" -- are you keeping your "archival data" in RAM? Seriously? No digital media of any kind will lose data without power. Many archives use optical disks, which can be read with equipment that could be powered by a stationary bicycle. I think you're overestimating the robustness requirements for archives. If you can't power the archive reader because nobody has enough power for it anywhere, the human race has much bigger problems than immediate access to a 100 year old film -- which nobody would be able to project anyway without electrical lighting. Get a grip.
"constant upgrades of gear" -- which is actually a benefit. With analog, you can't upgrade your gear, whereas with digital, the archives that used to take up a whole building will eventually neatly fit into something the size of a thumbnail. The cost of preservation will drop to pennies instead of millions of dollars. Keeping dozens or even thousands of redundant copies will become easy. With analog, nothing like that will ever happen. A roll of film will continue to take up exactly the same amount of shelfspace it always did.
One estimate is that the US Library of Congress has about 300 TB of accumulated archival data. This is just 100x 3TB hard drives. That's a pile of drives about the size of a small suitecase that would cost under $20K. Now stop and think for a minute... the entire LoC, in your room, for $20K. Seagate has just announced a 4TB hard drive. Manufacturers are developing patterned media and hybrid laser/magnetic storage. Rumors are that 10TB will be doable. Do you see a pattern emerging? How long do you think it'll be before you can just have the entire library of congress on a single drive, in the palm of your hand? Not robust enough for you? Buy two! Or two dozen! Every year! It'll cost less than what the LoC spends on coffee for their staff!
Let me rephrase that for you: ...I want to be able to hear the nuclear engineer talk about what it was like to be inside the reactor, shrug off the risk, and feel proud that someday people will go where I would never have dared. Robots have their place to prepare the areas to live and all that, but there is no substitute for actual people.
It sounds stupid, but it's directly comparable. Space is full of deadly, ionising radiation, and that is actually the least of the hazards! How is it a good thing to send someone into that environment needlessly, when there are robots available to do it? Should we decommission the robots used in nuclear engineering so that the brave engineers' widows can be proud of their noble sacrifice?
Every time some science fiction fan like you gets all dreamy about space colonisation, ignoring the harsh realities glossed over in fiction, I like to give this challenge:
If you think it's so fantastic living isolated from the rest of humanity on a cold rock in a hard vacuum, and that you'd just "jump" at the opportunity, then move to Bouvet Island, with the following rules: you have to carry everything you'll ever need with you (including air), delay radio communications by ten minutes, have a one year delay on any visits or assistance, the building at the destination has to be airtight, and you never get to leave it unless dressed in a head-to-toe scuba gear. Also, for every pound of material you take with you, donate $100 to your favourite charity. For extra realism, sprinkle some radioactive material around your dwelling and take medication that causes osteoporosis.
All the fun of space, for a fraction of the cost, and you can do it right now! Why delay?
You're off by a digit.
The James Webb Space Telescope is going to cost about 10 Billion by itself, and it's just a single-rocket unmanned mission that doesn't go anywhere near as far as Mars!
NASA's yearly budget is already over 15 Billion. It's a safe bet that a mission to the Moon or Mars would take at least a decade, and NASA's budget would have to double at a minimum. That's a 150 Billion right there, as a lower bound. More realistically, like you said, NASA's budget would have to increase manyfold, and mission would take longer. That implies a cost of over a trillion dollars.
Note that this isn't like the bailout, which were loans that were eventually repaid. This is a trillion dollars that are going to be launched into space, never to come back.