We also received 'end of the year' checks for $1,000 after taxes and our bonus is usually around 10% of our yearly gross (so anywhere from $11,000 to $20,000 for most employees). No, not just $450, a $450 gift plus $1000 bucks, plus a large bonus, and if $11,000 is 10% of their low-end pay.... holy shit nothing to complain about there.
Well... first off, it's got nothing to do with Linux. What we're talking about is a user interface that runs on top of X-windows. As such, it will run comfortably on any flavor of BSD or commercial Unix, and even stranger operating systems. We're talking about something well integrated with the low-level hardware and the GUIs ability to manipulate/work with. If the low level stuff+GUI together do not acheive things like hotplug media management (i.e. flash drives, music players, cameras, etc all auto-plugging), and systems administration task. As an example of this, I use Ubuntu normally. It is a good example of a totally integrated top to bottom desktop system. I install it, it automatically sets up everything. I plug in a flash drive, it auto mounts, same with a CD, it did detect and pop up a music player when my iPod plugged in. I have a wealth of administration/preference tasks available from the menu that wok well. My laptop clocks down/up as appropriate, and can sleep easily (and from the shutdown menu). Compared to Windows in terms of the basic functions a laptop needs to do, I want for nothing.
I recently tried a Solaris Nevada build (I really am intrigued by ZFS), which can be a good example of substituting for linux under the covers on the same GUI. On some level, the Gnome desktop is pretty similar, and it handled at least removable media well, but attempting to use the 'administration' menu (which was much less populated to begin with) left me at mostly dead ends (user management failed silently for example). Also, because of current limitations of the OpenSolaris kernel, no cpu frequency scaling on my particular laptop, no battery information (the kernel didn't like my ACPI table, which Intel's compiler and Linux have no complaints about), and of course no form of suspend or hibernation. No matter how shiny/easy the GUI on top, if the underpinnings don't enable the features desktop/laptop users need/want, it isn't a viable desktop platform. It's a very beta edition of Solaris, so the administration stuff in particular is not an overly fair evaluation of Solaris in its entirety, but the GUI bit is fairly stable and by your logic that's all that is needed.
Also, you couldn't just click and run with the few binary linux applications/plugins. No flash 9 beta, no adobe acrobat reader (though I always use evince, but this is an example), etc. They have solutions you can work around with 'BrandZ' with effort, but it is an example that more matters than just the layer above X. This is the same reason why Windows will maintain a lead for at least a long while, third party applications support Windows more than anything else.
As to the rest of your post, it's true that there is a great amount of diversity in the open source community, but that doesn't mean you need to compromise that to acheive a consistancy. You mention Gnome, KDE, and GNUstep, and saying their existance means there is no 'standard' UI. If you take the larger scope, that is true to an extent, but at the smaller scale of a single implementation of a desktop, it doesn't have to be. For example, the main Ubuntu distribution clearly the standard GUI is Gnome. Nearly every application has a counterpart in the two leading environments. KDE has amarok, Gnome has rhythmbox. Gnome has totem, KDE has Noatun (or whatever it is nowadays). Just because each camp has their own applications, doesn't prevent an organization from putting together a distribution using only consistant apps and largely ignoring the applications that don't fit in their vision.
Towards the end, IBM's choice of laptop hardware and their BIOS ACPI tables worked very well with Linux. IBM's support may translate some, since Lenovo started from a good position and were not necessarily inclined to deviate for no reason (Also, Lenovo bought the employees too, so the tendency would be strong). My biggest concern is if they continued to take care to do the ACPI tables properly or not going forward, but having the same firmware developers gives me hope.
Re:"Support" model seems to be a misnomer
on
Red Hat Sales Surge
·
· Score: 1
As you can see, RedHat was not defending its Linux distribution. It was defending its trademark. If you consider the trademark laws in USA, you will have to agree that RedHat really had no other option. Yes, to a point. However, we are using the Red Hat name right now in our comments. This sort of dialog is being forbidden by Red Hat on CentOS' web site as well.
Anyway, I'm glad both exist. RedHat for my gripes proves the viability of the platform as a professional endeavor, and CentOS' existance is a nice check and balance to remind RH what the GPL can mean to them, and, of course, to let users partake of whatever RedHat does achieve.
Now you have me really interested. I'm not sure about video, but I do know the XServe uses EFI instead of BIOS, so when you get to it through IPMI you're sitting in a full command shell where you can load and unload drivers, etc. Not really relevant to IPMI, IPMI is too low level to interact much with the OS/drivers. Interaction with BIOS/EFI is generally limited (i.e. setting some boot options, clearing CMOS config. Interaction with the running OS would be very limited generally (though with a BMC driver loaded, OEM commands could exist to do stuff, but the most I've seen is a BMC as watchdog to reset/power down hung systems and panic handler that logs what the kernel will give it, in a standard SEL event, and optionally encoding the panic string as an OEM event).
Now with IPMI 2.0, the serial port should probably be exported by the BMC via the network, which would give you a serial console regardless of EFI or BIOS (any BIOS on a IPMI system should support serial console, and any decent server OS has serial console support). Easy access to the system serial console may be what you are thinking of.
EFI does, however, provide a much more standard interface for the OS to the low level stuff, similar to OpenFirmware. On most PC BIOS systems, there are solutions like ASU that IBM does, but each vendor has his own. Of course, since Intel and Apple are the only ones providing EFI systems, it really isn't better than the vendor specific stuff unless more vendors adopt it...
Re:"Support" model seems to be a misnomer
on
Red Hat Sales Surge
·
· Score: 1
Only read the news, and the measures you describe are the acts I said clearly demonstrate their distaste for CentOS. Ultimately, they have to and do accept CentOS's existance (otherwise the nastiness you describe would be just the tip of the iceberg, and the reason why I bet they wish they were a BSD that wouldn't have to put up with that crap if they wanted.).
I would also add that lack of major releases is not an indication of the death of the linux desktop. As an example, WinXP released in 2002, and in 2006 they hadn't had any "major updates", and only 2 "minor updates" (the service packs weren't necessarily minor, but by this guys definition...) We can therefore rejoice, as Windows is a dead platform by that measure!
Re:"Support" model seems to be a misnomer
on
Red Hat Sales Surge
·
· Score: 1
The stuff as an outsider I've noted are some nastygrams from RedHat toward CentOS on copyrighted stuff they can legitimately get CentOS on for not being careful enough about replacing. It's not overly damning, but it is an example of them making life harder on the CentOS guys.
Re:"Support" model seems to be a misnomer
on
Red Hat Sales Surge
·
· Score: 4, Insightful
I think also saying they make their money from "support" may be a strong word, but it isn't so far off, they make money by selling the promise of support. I've seen numerous installations where the organization deploying knew for all practical technical reasons, they could go with either RHEL or CentOS and have the same experience. However, they were willing to pay for the support contract they more often than not never use.
This is not new to the business, or even the *nix world. Few years back I was part of a Solaris admin team. Before I joined, they already subscribed to a really expensive SMB server product for Solaris, which charged ungodly amounts monthly for even just a 2 concurrent client access license. I recognized that users were understandably upset over being 200 people who could rarely access their files from their windows boxes unless their department ponied up funds for a commercial nfs client for windows. I suggested samba as a viable alternative, but was denied because they couldn't possibly call for support at the time. I asked if they had ever actually called the vendor for support, and the answer was no, but they perpetually lived in fear of having to, so they paid the exorbitant fee.
It *seems* like they are selling an essentially free product hoping no one will notice, but the customers are mostly damn well aware of the free alternatives, and they make the conscious decision. Liability in a sense of the word is applicable. If IT uses their budget such that they have a couple more servers with money saved from not buying RHEL licenses, no one will notice or give them praise. However, if it hits the fan, even if the technical result ends up the same, if CentOS was installed, the finger pointing stops at the IT dept, if RHEL was installed with support contract in place, IT can redirect the finger to RedHat as not delivering on promises if it comes to that
As to your points:
A) RMS/GNU will complain that Redhat is violating the spirit of the GPL by not providing 100% equal access to free-loaders and then change the GPL Not likely, CentOS is the perfect counter-example that RHEL is following the GPL fine and the license is working as intended without loopholes. RedHat hasn't been overly noisy, but some acts they've done clearly demonstrate they aren't keen on the existence of CentOS, but accept they can't do anything about it.
B) One or several competing corporate entities will successfully be able to offer the same updates (so-called "support") by free-loading off Redhat's efforts... That is in essence what Oracle is doing. That's one of the scary competitors that RH has been talking about. If they were too successful in impairing RH's ability to fix the core stuff, they must either pick up the slack themselves or the product will perish (much like a parasite that gets too greedy will die when the host is killed). Too soon to tell if this relationship ends up parisitc (but perhaps mostly harmless) or symbiotic.
C) Redhat will be forced to include some proprietary software that will truly seperate them from the free-loaders... At one point I know RH shipped with the package some extras, including a JRE. Don't think they've done anything serious yet outside of GPLed projects. That does seem like a reasonable path if Oracle or Novell start achieving overwhelming success and RH is finally forced to differentiate themselves from the competition on a technical level.
When I have a choice, I go with a debian derivative. However, more for technical reasons. Red Hat even before the Fedora core days had a bad habit of making wrong decisions (i.e. gcc "2.96") during each 'dot-oh' release, and evolving something stable in.1,.2,etc.. Fedora Core reminds me a lot of classic RH without anything but dot-oh releases in the installs I've seen, and reserving.1,.2,etc like stability for RHEL (and derivatives). The RHEL stuff I'm still not big on, but it does seem to at least be manageable. I don't think it's all that bad, their preferred vision of the world consists of only Fedora Core for enthusiasts/testers/developers, and RHEL for companies, but the reality is there are more options, even if you want to stay true to RH, CentOS is a viable option they can't get rid of.
What I am a bit frustrated with is RH people tend to think they are solely responsible for the widespread adoption of linux. I wasn't surprised that some of the most annoying devs I worked with ended up at RH (though they do have some cool devs there too). I'd wager the business types wished RH would have pushed a BSD platform, so they could close it up for the Enterprise install and have a relationship closer to OpenDarwin/OSX between Fedora and RHEL. They probably think any platform they would have chosen they would have made a winner...
Anyway, enough of my RH rant...
who is the fuck-ass who thought up using cpio with a fucked up header on it so you have to use dd (or however... something) before you can even manually unpack the archive? I think RPM is seriously lacking in flexibility, but your statement seems to imply a grave misunderstanding of cpio (dd??). What real benefit do you have from using tar or ar (debian uses ar currently)? They picked a perfectly viable archive format and went with it (the cpio format they picked has no particularly quirky limitations I am aware of).
My basic gripe about RPM is that is is fairly simplistic. You have dependencies and provides, no suggestions or recommendations. Also, no diversions seem to be possible in modern rpm implementations, if two rpms have the same file in their archive, they will conflict with no graceful way around it (a la dpkg-divert).
My other gripe that has little to do with RPM design itself is that a lot of uncaring/naive developers putting crap in pre and post-scripts that don't belong. I.e. cping files around really screwing with the reliability of rpm -qf...
If you think 2002 was the end of it all, install a distribution that was current in 2002, or hell, half way into 2003. That ought to refresh your memory as to how things changed. I still support systems running that stuff.
The problem is the author is one of these people that are the cause of marketers demanding n+1.0 releases to give the perception of great advancement. In Gnome 2.0, I think they reached the fundamental model that to me seems to be pretty much where they want to be, but that hasn't meant it didn't change drastically since then. Some of those 'bits of functionality improvements' have been fairly significant, and critical to a desktop platform, and keeping pace with OSX and Windows visual effects capabilities (i.e. Cairo and working toward Metacity compositing). From things as basic as a persistent clipboard, to things like numerous overhauls of nautilus, the mime-type systems, menu editing, embracing the freedesktop standards, new file chooser dialogs, and extending their platform to include more system administration standardization and various necessities (i.e. a screensaver consistant with the desktop).
Though there are some significant differences between gnome 2.0 basic layout and gnome 1.x basic layout, keep in mind that at least to this point Gnome major version is tied to the basic toolkit, which has essentially achieved the basic functionality they needed. Gtk 1.x was ass ugly, and not flexible enough to cleanly adopt new rendering strategies, and gtk 2.x corrected it and improved flexibility that has so far avoided the need for gtk 3.x.
Same for KDE, though IMHO, gnome spent more time struggling with what they wanted their vision to be, while KDE early on were content with their results. When I went from KDE 2.x to 3.0, it didn't feel significantly different. Again, they tie their major releases to their toolkit, QT. If QT never released 4.0, the 'revolutionary' 4.0 features for the most part would be in a KDE 3.n+1.
All this assumes also that all desktop 'innovation' can only come from the main progression of the GNOME/KDE projects. Compiz and Beryl have shown the way to advanced compositing with AIGLX/Xgl/nVidia-specific calls, for those OSX/Vista effects (and more). Ubuntu ties its release closely to the Gnome schedule, but the focus and integration of things in and out of gnome is critical to a good desktop system. Thanks to all the work in Gnome, the kernel, and other people and distros like Ubuntu doing the work to pull it all together,my desktop is as functional and nice looking as OSX or Windows. I can insert and remove media, and have it mounted and unmounted with ease, I can put my laptop to sleep and have it reliably wake up. I never want for a Windows desktop.
My only regret about the linux desktop is that GNUstep is not progressing more quickly. There are things about the NeXT/OSX interface strategy I really like, but GNUstep, despite some strides, progresses slowly overall and even with theming (Nesedah looks fairly nice), it is hard to get it to look nice yet clean.
I do have two comments on them: -LED replication in the front, good thing. I don't know many servers that bother to put all the typical operation LEDs up front. Honestly, though, I haven't heard people want more than all the error LEDs up front. IBM servers do that part (easy to tell if the server thinks something is wrong at least, no LEDs=good thing, but having the NIC LEDs up front could be helpful (or a negation of the link light...)
-Lack of apparent front side video, bad thing. 1U servers are frequently cabled up without any KVM or anything. Unless their BMC implements remote video, and for the most part even if it did, hot plugging monitor and keyboard to the front of the server to not disturb cabling in the back is handy.
I'll go to the website at a glance to see if the biggest gripe is still valid...
Ok, so the Intel XServe does away with the biggest complaint I *think*. Looks like they have an IPMI 2.0 compliant BMC, and the complaint I had heard before was a severe lack of out of band management. I shouldn't be surprised that in moving to the Intel design intel helping them correct this. So their server hardware is not as out of touch as they used to be, but interest remains low among the customers I deal with. Note I couldn't get the info easily from Apple's web site, I went to external review sites to find out what management they had. Apple's marketing for a server isn't the best for anything larger than small business. They gloss over details that are critical to IT organizations. Saying "IPMI compliant" may not be plain enough speak for the PC market, but in the server market that detail should be more clearly stated..
Hard to know where to start. Do you work for Microsoft?
Hardly. I know MS software implements *some* of the alternatives I suggested, but I don't think they have a very robust storage management (i.e. at last check I did they lacked standardized multipath, snapshots, some other things.
-ZFS RAID: ZFS does full stripe writes, all the time, which are the fastest software RAID writes, thanks to variable stripe writes. This does, in fact. obsolete mid-range HW RAID, let alone the cheap PCI RAID cards.
I think what you are getting at is the filesystem-level knowledge ZFS has available to optimize performance above and beyond block-level possibilities that I mentioned. Ultimately its complicated, don't have hard performance data on the 'RAID-Z' stuff, but already software raid was a viable solution, depending on CPU time spent nominally idle vs. what could be offloaded by a dedicated XOR engine. Even given equal performance, I'd pick software RAID for hardware independence. RAID-Z likely outdistances traditional RAID[345] approaches in theoretical best, but don't know if the offset is really that much to be excited about.
-Self-validating the data store is independent of RAID. If you don't understand this, it is back to school time.
But you seemed to indicate self-recovery/healing beyond validation ("no bit rot"). I was simply saying that ZFS requires the pool be built in specific ways for self-recovery, which is to be expected, but ZFS does nothing magical to fix data if no redundancy is in place, which is a fair assessment, but statements like 'no bit rot' imply ECC strategy to correct errors rather than simple checksumming for more absolute error detection. This isn't a bad thing, but ZFS should be presented correctly.
File systems are supposed to be independent of the underlying infrastructure.
Ah, but this isn't a good thing, and one of the huge benefits of ZFS is just that it is not so independent of the underlying structure, so they can leverage stuff. Hence why they recommend adding individual disks in raidz to the pool over setting up a block-layer RAID5 underneath the storage device.
-Apple engineers can figure out how to boot from it. Not a priority for Sun, whose E10K's required an internal SCSI disk for years to boot.
Hard to say, they may continue to have a simple small bootstrap partition, or else they may need openfirmware updates if they do want ZFS boot. Current openfirmware implementations may not be able to boot ZFS directly, but that doesn't mean a small simple volume could begin to even be noticable to users. Volumes will continue to exist, but that doesn't mean the storage pool concept won't make things immensely easier.
-Versioning isn't the same as CDP, as you well know. Since snapshots in ZFS are cheaper than overwrites, it would be simple - and I have no idea what APPL engineers are implementing - to snapshot before every ~Documents write.
Possible, but snapshots may not be *so* trivial or important to do so frequently. Time machine seemed to have daily granularity. I've implemented down to hourly snapshots with dirvish within a day, and ZFS would be a lot lighter weight than that, so I wouldn't doubt hourly, but there probably should be a limit.
-Today's set-top boxes aren't hoping you will spend thousands of dollars purchasing copies of content that they won't let you backup. ITV is. So Apple is suddenly going to offer a generic set-top box? WTF?
I'm saying the market expectation is low, so Apple doesn't need to cram two hard drives in there and by extension price themselves up. Look at iPods for precedent, they are by no means redundant by default. I would expect 'iTV' to be very closely modeled off of the iPod strategy, except it probably will allow users external storage options. Personally, no level of making my one basket secure makes me feel better about having all my DRMed eggs being force
Forks/duplications of efforts can have negative repercussions, but they are not without reason. A fork reflects a difference of opinion on how to proceed. Duplication of work occurs on similar goals, but one of two things happen. Either the reason behind the fork was not really popular or not sufficiently different to pursuade userbase and the fork dies, or the cause for the work was justified and the fork lives on or overtakes the original.
Can probably point out tons and tons of failed forks (I believe mplayer has had a few unsuccessful forking attempts). They happen all the time.
A shining example of a 'fork' like endeavor coexisting with the original is Debian and Ubuntu. Ubuntu has a set of technical and marketing goals that didn't mesh perfectly with Debian. Ubuntu was justified and the community has greatly accepted it. Meanwhile Debian has not really lost much in its userbase (most Ubuntu users come from RPM based distros rather than Debian) because the concepts Debian hold as important still matter.
And sometimes fork reflect the need to meaningfully continue a project that has for all intents and purposes lost touch. Xorg is a fork of XFree86 that has effectively killed off the original. They still twitch, but they've even taking down their ultimately embarassingly list of distros that still supported them (generally by not having updated yet rather than a concious future decision). The breaking point was a licensing technicality, but it's clear that XFree86 had technical problems as well in adopting new graphical features.
Hell, linux itself is spiritually (not technically) a fork of minix. The basic point is simple, projects by and large once established tend not to do revolutionary new things as the people at the head are heading basically where they meant to go. Forking is a logical way for revolutionary change to happen and the userbase decides the fate of the original and new.
The game plays out on the screens of the main command centre at NORAD and, unable to tell that what they are seeing is not real, a retaliatory strike is nearly launched I haven't seen the film in years, but I still can't imagine how someone could misremember it like that. The humans were not controlling the response, the computer was. Hence the whole 'play tic-tac-toe with itselfs'. They were watching the computer prepare to launch the strike and it wouldn't listen for some long-forgotten reason.
The blurb is really confusing "Ripley has been designed to appeal to potential terrorists, and certain glitches have turned made him become paranoid. ", wtf does that mean?
There is a scenario I could think of that could mimic the War Games Scenario, on a somewhat reduced scale, related to the most common domestically feared terrorism attack, hijacked planes. Ripley could decide all passenger jets in the air are hijacked and control automated missile batteries to threaten all flights... Toss in some key characters on flights to bring the viewer more into it. It certainly doesn't speak to the MAD message that was central to War Games, but I doubt the studios have a particularly deep meaning in mind...
I seriously doubt this movie will be remotely good, but there exists potential for some of the fundamentals of the first movie to play out in the terrorist context..
No RAID controllers needed: ZFS gives you fast RAID for free. Just add drives.
Not particularly new, systems have been fast enough for general software raid for a long time. ZFS has the opportunity to leverage FS-level knowledge to milk some efficiency out of things that block-level approaches cannot, but ultimately ZFS isn't obsoleting the need for RAID controllers any more than software RAID already has. I admit that there are a lot of proprietary RAID controllers employed where they shouldn't be, but that's not a technical problem, it's a perception problem, ZFS won't fix that.
-No more Disk Warrior. The entire data store is self-validating. No bit rot.
ZFS doesn't mandate the storage pool be implemented in any particularly redundant way. If you have just one drive, it's fairly obviously non-redundant. If you add a second drive, it may or may not be a mirror of the first one, depending on how each was added to the pool. Every indication I have seen shows that ZFS checksumming helps detect data integrity errors, and does not implement ECC. It detects block-level silent data corruption, and if the pool is configured just so, the subsystem can reroute things and alert user to service need. If Apples always ship with two drives, it could get clever, but it isn't magical.
-No more volumes and, therefore, no more volume management. ZFS eliminates the whole volume concept. Add a disk to your system and it joins your storage pool. More capacity. Not more management.
For the most part ZFS simplifies it, but not all storage will be wanted in the pool. One shining long term example is removable media (optical and flash). Another is so far, even Sun hasn't figured out how to boot from it, so you will have some volume management still, just adding an external hard disk can be made much much easier than under Linux or Windows.(New uninitialized device detected, add to (cute volume name) or...
-Continuous Data Protection out of the box. Time Machine could give you a view of your data every time you update a file.
ZFS as far as I can see is not a versioned filesystem where every single modification is tracked. It has built-in snapshotting functionality, and therefore makes an easy way to implement time machine backend (or at least offloaded to Sun to sweat the details instead of Apple), perhaps even lower impact at snapshotting time than Time Machine's current implementation, but it won't continuously track changes.
-ITV, or whatever it is going to be called. Multi-GB files that each cost $10-20, that can't be backed up - thanks DRM! - and therefore need a cheap and highly reliable RAID. ITV, two firewire drives, ZFS and you are in business.
Not enough details are available to ascertain how it will work, but while the savvy get the point (my Myth setup separates backend and frontend to have more robust, but noiser measures to protect stuff), by and large mass-market set top boxes get away without redundancy.
-Not to mention the existential pleasure of having great technology that Vista doesn't have. In fact, since consumer technology is driving the enterprise, expect ZFS on Mac to raise the bar for every OS and file system.
ZFS on Mac will likely do little to nothing to raise the bar in the enterprise beyond Solaris doing it. I admit ZFS is the one nugget Sun has brought out for Solaris that has me curious, but OSX's embracing it didn't extend it more. ZFS is among their biggest assets, and they clearly want either revenue or Solaris acceptance from it (hence licensing that precludes it from linux, their primary competitive solution). I think someone was on to something when they discussed the Sun/Apple relationship long term. Solaris, *particularly* thanks to ZFS can perform server-side tasks competently and still has some mindshare. Solaris workstations, however, are largely considered unneeded and counter-productive in ease of use nowadays. Apple has
sleep works great on my R50, except with edgy they botched the radeonfb D2 sleep mode stuff, had to migrate the patch from dapper, which did it right. Of course, they don't load radeonfb by default, so my laptop without my effort would have used 5W instead of 500mW in sleep... But if not using radeon, I bet it'd be great without sweating it.
Can't speak to hibernate, I never need to hibernate and I use a dm-crypt swap partition, so I suspect I wouldn't be able to do it if I wanted too.
I agree to your doubts that ZFS will be involved in Time Machine (since Time Machine was seemingly demoed before ZFS support was added, their ZFS support would be too new to bank a new feature on that many people will use, and there are many many more traditional ways of implementing snapshots using block layer tricks and filesystem-aware tricks). However, based on the description, ZFS *could* have been required for Time Machine:
Right from the start, Time Machine in Mac OS X Leopard makes a complete backup of all the files on your system. That includes your system files, applications, accounts, preferences, music, photos, movies, documents -- everything you keep on your Mac. As you make changes, Time Machine only backs up what changes, all the while maintaining a comprehensive layout of your system. In this case, it talks about requiring a new, unformatted drive. It could format the new block device as ZFS, copy all the current data to that backup volume, then leverage ZFS snapshotting features rather than whatever mechanism they probably did use. If it used ZFS, doesn't mean it requires the source volume to be ZFS formatted....
I think the pentium 60 mhz was considered about the same as the 100 mhz 486s that came out at the end of the 486 days.. except for dividing floating point numbers of course..
I only recently decommisioned a P60 box that was router in favor of a much more efficient WRT box. Too bad that 286 in the closet I can't possibly conceive a use for anymore...
people making homebrew PS3 games (not just 2d stuff) that are as good or better than "real" PS3 games Look at the extremely wide open personal computer platform over the years. How many non-puzzle original games in the homebrew scene are something companies should worry about? Even when trying to copy a game functionally, generally the free art the community comes up with detracts horribly from the original. Notable free games I can think of are several puzzle games (i.e. frozen bubble), Freeciv (which has decent independent art, only just many years after their commercial inspiration), Ur-Quan Masters (which is just SC2 ported after 10 years, and various games played via emulation (obviously not original).
They are clearly worried about people leveraging linux support to get around protections that prevent playing copied games, and have essentially made the linux support worthless (in true Sony fashion). Sony isn't stupid, and you are too optimistic in the homebrew scenes ability to outproduce large-budget, full work-week efforts by large companies.
I'm evaluating the tips based on them being prescriptions for things to do in interactive shell behavior, since that seems to be the theme. Writing scripts changes the situation to make some tips valuable. My number one tip as a response to these is don't try to be too clever (particularly when the biggest benefit of the approach is to say 'look how clever it is!'). Maybe it's because I don't work in a vacuum and all too many times have been called in to clean up where an administrator tried to do something too complicated for their understanding.
mkdir -p is a convenience people should be aware of, but telling people to start getting overly creative with the shell expansion behavior is asking for mistakes/trouble. Also, having a mkdirhier script in case the example isn't supported on all shells is an indication that you shouldn't get overly cozy if you are going to be dealing with a lot of different systems/users with different default shells. The amount of time a lot of people take to figure out the 'clever' way in terms of how to phrase the expansion so the shell will expand it right is often longer than just typing the two lines more that the less thought takes. Not saying this isn't useful, but in my experience too many people mess things up too frequently or take too long to think up the expressions to tell them trying to be clever ends up taking more time than they think they are saving.
Change the path instead of the archive is not that dire to do normally, but if you avoid it, to me it's just easier to be in the target directly and use full path to the archive.
On combining commands, I second that ; can be dangerous and && as a default will make the chain more ready to break, but again I say not trying to be so clever as to put all you want on one line. Some things go wrong that aren't reflected in return codes, doing it one at a time let's you think of those. True, though, that the && never assume the first command works, while your fingers may keep moving and hit enter on next command before your brain realizes the command failed, so && may have merit, but then again taking your time may have more merit.
On the quotation thing, true enough, you must understand how quoting works to do remotely complex things, particularly nested circumstances (i.e. ssh to a system to run a command, where the output will be parsed by two shells.)
On the breaking up long lines thing, in a shell script it may be more necessary, but on an interactive command line it could also indicate you are trying too hard to do things in one chunk. I admit sometimes it does get too wide, but particularly less experienced admins should consider if there were a simpler way to do it in smaller chunks they won't screw up.
Grouping commands is important to know, and harmless (better than repeating the same pipe over and over and more powerful).
I will say xargs is way way over-rated. Too many people, particularly dealing with directory trees containing spaces, get into trouble piping the output of find into anything when IFS causes something like "/tmp/Monthly Report" to be parsed as two different files. find has a competent filtering mechanism (-type, -iname, -name, etc...) and it's own -exec. find is well aware of the state of each file. You could assign IFS to try to avoid it, but using find's built-ins where possible alleviates it.
When you are talking about interactive shell operation, picking the.01s instead of the.09s operation is a bad example. He could have set up a much larger demonstration that would have been useful, but this just makes people mock the example. In any event, this seems like an okay thing to convey, but I dunno if it would've made my top 10.
Probably a more valid point about using awk, and a common trap I do see people stuck in.
On piping cat, that seems like more an annoyance than anything constructive. Some people use the cat | grep construct because it is so unambiguou
Actually, this case is a very good example of why && are better as a default over ; to delimit commands on a single line. If you were in/, wanted to delete/tmp/root, and you typed cd/tm;rm -rf root. You'd be in trouble, but the && would cause the failed cd to not hose things up.
Still, my advice in general would be to avoid stringing commands just for the sake of being clever and run each command serially. More can go wrong than the return code will indicate that output will.
Slashdot Mirror
It's a celebration of the Winter Solstice, you insensitive clod.
I think I might need to work in Big Oil now...
I recently tried a Solaris Nevada build (I really am intrigued by ZFS), which can be a good example of substituting for linux under the covers on the same GUI. On some level, the Gnome desktop is pretty similar, and it handled at least removable media well, but attempting to use the 'administration' menu (which was much less populated to begin with) left me at mostly dead ends (user management failed silently for example). Also, because of current limitations of the OpenSolaris kernel, no cpu frequency scaling on my particular laptop, no battery information (the kernel didn't like my ACPI table, which Intel's compiler and Linux have no complaints about), and of course no form of suspend or hibernation. No matter how shiny/easy the GUI on top, if the underpinnings don't enable the features desktop/laptop users need/want, it isn't a viable desktop platform. It's a very beta edition of Solaris, so the administration stuff in particular is not an overly fair evaluation of Solaris in its entirety, but the GUI bit is fairly stable and by your logic that's all that is needed.
Also, you couldn't just click and run with the few binary linux applications/plugins. No flash 9 beta, no adobe acrobat reader (though I always use evince, but this is an example), etc. They have solutions you can work around with 'BrandZ' with effort, but it is an example that more matters than just the layer above X. This is the same reason why Windows will maintain a lead for at least a long while, third party applications support Windows more than anything else.
As to the rest of your post, it's true that there is a great amount of diversity in the open source community, but that doesn't mean you need to compromise that to acheive a consistancy. You mention Gnome, KDE, and GNUstep, and saying their existance means there is no 'standard' UI. If you take the larger scope, that is true to an extent, but at the smaller scale of a single implementation of a desktop, it doesn't have to be. For example, the main Ubuntu distribution clearly the standard GUI is Gnome. Nearly every application has a counterpart in the two leading environments. KDE has amarok, Gnome has rhythmbox. Gnome has totem, KDE has Noatun (or whatever it is nowadays). Just because each camp has their own applications, doesn't prevent an organization from putting together a distribution using only consistant apps and largely ignoring the applications that don't fit in their vision.
Put more work behind GNUstep. The natural evolution of GNUstep is a viable OSX alternative.
Towards the end, IBM's choice of laptop hardware and their BIOS ACPI tables worked very well with Linux. IBM's support may translate some, since Lenovo started from a good position and were not necessarily inclined to deviate for no reason (Also, Lenovo bought the employees too, so the tendency would be strong). My biggest concern is if they continued to take care to do the ACPI tables properly or not going forward, but having the same firmware developers gives me hope.
Anyway, I'm glad both exist. RedHat for my gripes proves the viability of the platform as a professional endeavor, and CentOS' existance is a nice check and balance to remind RH what the GPL can mean to them, and, of course, to let users partake of whatever RedHat does achieve.
Now with IPMI 2.0, the serial port should probably be exported by the BMC via the network, which would give you a serial console regardless of EFI or BIOS (any BIOS on a IPMI system should support serial console, and any decent server OS has serial console support). Easy access to the system serial console may be what you are thinking of.
EFI does, however, provide a much more standard interface for the OS to the low level stuff, similar to OpenFirmware. On most PC BIOS systems, there are solutions like ASU that IBM does, but each vendor has his own. Of course, since Intel and Apple are the only ones providing EFI systems, it really isn't better than the vendor specific stuff unless more vendors adopt it...
Only read the news, and the measures you describe are the acts I said clearly demonstrate their distaste for CentOS. Ultimately, they have to and do accept CentOS's existance (otherwise the nastiness you describe would be just the tip of the iceberg, and the reason why I bet they wish they were a BSD that wouldn't have to put up with that crap if they wanted.).
I would also add that lack of major releases is not an indication of the death of the linux desktop. As an example, WinXP released in 2002, and in 2006 they hadn't had any "major updates", and only 2 "minor updates" (the service packs weren't necessarily minor, but by this guys definition...) We can therefore rejoice, as Windows is a dead platform by that measure!
The stuff as an outsider I've noted are some nastygrams from RedHat toward CentOS on copyrighted stuff they can legitimately get CentOS on for not being careful enough about replacing. It's not overly damning, but it is an example of them making life harder on the CentOS guys.
This is not new to the business, or even the *nix world. Few years back I was part of a Solaris admin team. Before I joined, they already subscribed to a really expensive SMB server product for Solaris, which charged ungodly amounts monthly for even just a 2 concurrent client access license. I recognized that users were understandably upset over being 200 people who could rarely access their files from their windows boxes unless their department ponied up funds for a commercial nfs client for windows. I suggested samba as a viable alternative, but was denied because they couldn't possibly call for support at the time. I asked if they had ever actually called the vendor for support, and the answer was no, but they perpetually lived in fear of having to, so they paid the exorbitant fee.
It *seems* like they are selling an essentially free product hoping no one will notice, but the customers are mostly damn well aware of the free alternatives, and they make the conscious decision. Liability in a sense of the word is applicable. If IT uses their budget such that they have a couple more servers with money saved from not buying RHEL licenses, no one will notice or give them praise. However, if it hits the fan, even if the technical result ends up the same, if CentOS was installed, the finger pointing stops at the IT dept, if RHEL was installed with support contract in place, IT can redirect the finger to RedHat as not delivering on promises if it comes to that
As to your points: A) RMS/GNU will complain that Redhat is violating the spirit of the GPL by not providing 100% equal access to free-loaders and then change the GPL Not likely, CentOS is the perfect counter-example that RHEL is following the GPL fine and the license is working as intended without loopholes. RedHat hasn't been overly noisy, but some acts they've done clearly demonstrate they aren't keen on the existence of CentOS, but accept they can't do anything about it. B) One or several competing corporate entities will successfully be able to offer the same updates (so-called "support") by free-loading off Redhat's efforts... That is in essence what Oracle is doing. That's one of the scary competitors that RH has been talking about. If they were too successful in impairing RH's ability to fix the core stuff, they must either pick up the slack themselves or the product will perish (much like a parasite that gets too greedy will die when the host is killed). Too soon to tell if this relationship ends up parisitc (but perhaps mostly harmless) or symbiotic. C) Redhat will be forced to include some proprietary software that will truly seperate them from the free-loaders... At one point I know RH shipped with the package some extras, including a JRE. Don't think they've done anything serious yet outside of GPLed projects. That does seem like a reasonable path if Oracle or Novell start achieving overwhelming success and RH is finally forced to differentiate themselves from the competition on a technical level.
What I am a bit frustrated with is RH people tend to think they are solely responsible for the widespread adoption of linux. I wasn't surprised that some of the most annoying devs I worked with ended up at RH (though they do have some cool devs there too). I'd wager the business types wished RH would have pushed a BSD platform, so they could close it up for the Enterprise install and have a relationship closer to OpenDarwin/OSX between Fedora and RHEL. They probably think any platform they would have chosen they would have made a winner...
Anyway, enough of my RH rant... who is the fuck-ass who thought up using cpio with a fucked up header on it so you have to use dd (or however... something) before you can even manually unpack the archive? I think RPM is seriously lacking in flexibility, but your statement seems to imply a grave misunderstanding of cpio (dd??). What real benefit do you have from using tar or ar (debian uses ar currently)? They picked a perfectly viable archive format and went with it (the cpio format they picked has no particularly quirky limitations I am aware of).
My basic gripe about RPM is that is is fairly simplistic. You have dependencies and provides, no suggestions or recommendations. Also, no diversions seem to be possible in modern rpm implementations, if two rpms have the same file in their archive, they will conflict with no graceful way around it (a la dpkg-divert).
My other gripe that has little to do with RPM design itself is that a lot of uncaring/naive developers putting crap in pre and post-scripts that don't belong. I.e. cping files around really screwing with the reliability of rpm -qf...
If you think 2002 was the end of it all, install a distribution that was current in 2002, or hell, half way into 2003. That ought to refresh your memory as to how things changed. I still support systems running that stuff.
The problem is the author is one of these people that are the cause of marketers demanding n+1.0 releases to give the perception of great advancement. In Gnome 2.0, I think they reached the fundamental model that to me seems to be pretty much where they want to be, but that hasn't meant it didn't change drastically since then. Some of those 'bits of functionality improvements' have been fairly significant, and critical to a desktop platform, and keeping pace with OSX and Windows visual effects capabilities (i.e. Cairo and working toward Metacity compositing). From things as basic as a persistent clipboard, to things like numerous overhauls of nautilus, the mime-type systems, menu editing, embracing the freedesktop standards, new file chooser dialogs, and extending their platform to include more system administration standardization and various necessities (i.e. a screensaver consistant with the desktop).
Though there are some significant differences between gnome 2.0 basic layout and gnome 1.x basic layout, keep in mind that at least to this point Gnome major version is tied to the basic toolkit, which has essentially achieved the basic functionality they needed. Gtk 1.x was ass ugly, and not flexible enough to cleanly adopt new rendering strategies, and gtk 2.x corrected it and improved flexibility that has so far avoided the need for gtk 3.x.
Same for KDE, though IMHO, gnome spent more time struggling with what they wanted their vision to be, while KDE early on were content with their results. When I went from KDE 2.x to 3.0, it didn't feel significantly different. Again, they tie their major releases to their toolkit, QT. If QT never released 4.0, the 'revolutionary' 4.0 features for the most part would be in a KDE 3.n+1.
All this assumes also that all desktop 'innovation' can only come from the main progression of the GNOME/KDE projects. Compiz and Beryl have shown the way to advanced compositing with AIGLX/Xgl/nVidia-specific calls, for those OSX/Vista effects (and more). Ubuntu ties its release closely to the Gnome schedule, but the focus and integration of things in and out of gnome is critical to a good desktop system. Thanks to all the work in Gnome, the kernel, and other people and distros like Ubuntu doing the work to pull it all together,my desktop is as functional and nice looking as OSX or Windows. I can insert and remove media, and have it mounted and unmounted with ease, I can put my laptop to sleep and have it reliably wake up. I never want for a Windows desktop.
My only regret about the linux desktop is that GNUstep is not progressing more quickly. There are things about the NeXT/OSX interface strategy I really like, but GNUstep, despite some strides, progresses slowly overall and even with theming (Nesedah looks fairly nice), it is hard to get it to look nice yet clean.
I do have two comments on them:
-LED replication in the front, good thing. I don't know many servers that bother to put all the typical operation LEDs up front. Honestly, though, I haven't heard people want more than all the error LEDs up front. IBM servers do that part (easy to tell if the server thinks something is wrong at least, no LEDs=good thing, but having the NIC LEDs up front could be helpful (or a negation of the link light...)
-Lack of apparent front side video, bad thing. 1U servers are frequently cabled up without any KVM or anything. Unless their BMC implements remote video, and for the most part even if it did, hot plugging monitor and keyboard to the front of the server to not disturb cabling in the back is handy.
I'll go to the website at a glance to see if the biggest gripe is still valid...
Ok, so the Intel XServe does away with the biggest complaint I *think*. Looks like they have an IPMI 2.0 compliant BMC, and the complaint I had heard before was a severe lack of out of band management. I shouldn't be surprised that in moving to the Intel design intel helping them correct this. So their server hardware is not as out of touch as they used to be, but interest remains low among the customers I deal with. Note I couldn't get the info easily from Apple's web site, I went to external review sites to find out what management they had. Apple's marketing for a server isn't the best for anything larger than small business. They gloss over details that are critical to IT organizations. Saying "IPMI compliant" may not be plain enough speak for the PC market, but in the server market that detail should be more clearly stated..
Hard to know where to start. Do you work for Microsoft?
Hardly. I know MS software implements *some* of the alternatives I suggested, but I don't think they have a very robust storage management (i.e. at last check I did they lacked standardized multipath, snapshots, some other things.
-ZFS RAID: ZFS does full stripe writes, all the time, which are the fastest software RAID writes, thanks to variable stripe writes. This does, in fact. obsolete mid-range HW RAID, let alone the cheap PCI RAID cards.
I think what you are getting at is the filesystem-level knowledge ZFS has available to optimize performance above and beyond block-level possibilities that I mentioned. Ultimately its complicated, don't have hard performance data on the 'RAID-Z' stuff, but already software raid was a viable solution, depending on CPU time spent nominally idle vs. what could be offloaded by a dedicated XOR engine. Even given equal performance, I'd pick software RAID for hardware independence. RAID-Z likely outdistances traditional RAID[345] approaches in theoretical best, but don't know if the offset is really that much to be excited about.
-Self-validating the data store is independent of RAID. If you don't understand this, it is back to school time.
But you seemed to indicate self-recovery/healing beyond validation ("no bit rot"). I was simply saying that ZFS requires the pool be built in specific ways for self-recovery, which is to be expected, but ZFS does nothing magical to fix data if no redundancy is in place, which is a fair assessment, but statements like 'no bit rot' imply ECC strategy to correct errors rather than simple checksumming for more absolute error detection. This isn't a bad thing, but ZFS should be presented correctly.
File systems are supposed to be independent of the underlying infrastructure.
Ah, but this isn't a good thing, and one of the huge benefits of ZFS is just that it is not so independent of the underlying structure, so they can leverage stuff. Hence why they recommend adding individual disks in raidz to the pool over setting up a block-layer RAID5 underneath the storage device.
-Apple engineers can figure out how to boot from it. Not a priority for Sun, whose E10K's required an internal SCSI disk for years to boot.
Hard to say, they may continue to have a simple small bootstrap partition, or else they may need openfirmware updates if they do want ZFS boot. Current openfirmware implementations may not be able to boot ZFS directly, but that doesn't mean a small simple volume could begin to even be noticable to users. Volumes will continue to exist, but that doesn't mean the storage pool concept won't make things immensely easier.
-Versioning isn't the same as CDP, as you well know. Since snapshots in ZFS are cheaper than overwrites, it would be simple - and I have no idea what APPL engineers are implementing - to snapshot before every ~Documents write.
Possible, but snapshots may not be *so* trivial or important to do so frequently. Time machine seemed to have daily granularity. I've implemented down to hourly snapshots with dirvish within a day, and ZFS would be a lot lighter weight than that, so I wouldn't doubt hourly, but there probably should be a limit.
-Today's set-top boxes aren't hoping you will spend thousands of dollars purchasing copies of content that they won't let you backup. ITV is. So Apple is suddenly going to offer a generic set-top box? WTF?
I'm saying the market expectation is low, so Apple doesn't need to cram two hard drives in there and by extension price themselves up. Look at iPods for precedent, they are by no means redundant by default. I would expect 'iTV' to be very closely modeled off of the iPod strategy, except it probably will allow users external storage options. Personally, no level of making my one basket secure makes me feel better about having all my DRMed eggs being force
Forks/duplications of efforts can have negative repercussions, but they are not without reason. A fork reflects a difference of opinion on how to proceed. Duplication of work occurs on similar goals, but one of two things happen. Either the reason behind the fork was not really popular or not sufficiently different to pursuade userbase and the fork dies, or the cause for the work was justified and the fork lives on or overtakes the original.
Can probably point out tons and tons of failed forks (I believe mplayer has had a few unsuccessful forking attempts). They happen all the time.
A shining example of a 'fork' like endeavor coexisting with the original is Debian and Ubuntu. Ubuntu has a set of technical and marketing goals that didn't mesh perfectly with Debian. Ubuntu was justified and the community has greatly accepted it. Meanwhile Debian has not really lost much in its userbase (most Ubuntu users come from RPM based distros rather than Debian) because the concepts Debian hold as important still matter.
And sometimes fork reflect the need to meaningfully continue a project that has for all intents and purposes lost touch. Xorg is a fork of XFree86 that has effectively killed off the original. They still twitch, but they've even taking down their ultimately embarassingly list of distros that still supported them (generally by not having updated yet rather than a concious future decision). The breaking point was a licensing technicality, but it's clear that XFree86 had technical problems as well in adopting new graphical features.
Hell, linux itself is spiritually (not technically) a fork of minix. The basic point is simple, projects by and large once established tend not to do revolutionary new things as the people at the head are heading basically where they meant to go. Forking is a logical way for revolutionary change to happen and the userbase decides the fate of the original and new.
The blurb is really confusing "Ripley has been designed to appeal to potential terrorists, and certain glitches have turned made him become paranoid. ", wtf does that mean?
There is a scenario I could think of that could mimic the War Games Scenario, on a somewhat reduced scale, related to the most common domestically feared terrorism attack, hijacked planes. Ripley could decide all passenger jets in the air are hijacked and control automated missile batteries to threaten all flights... Toss in some key characters on flights to bring the viewer more into it. It certainly doesn't speak to the MAD message that was central to War Games, but I doubt the studios have a particularly deep meaning in mind...
I seriously doubt this movie will be remotely good, but there exists potential for some of the fundamentals of the first movie to play out in the terrorist context..
No RAID controllers needed: ZFS gives you fast RAID for free. Just add drives.
Not particularly new, systems have been fast enough for general software raid for a long time. ZFS has the opportunity to leverage FS-level knowledge to milk some efficiency out of things that block-level approaches cannot, but ultimately ZFS isn't obsoleting the need for RAID controllers any more than software RAID already has. I admit that there are a lot of proprietary RAID controllers employed where they shouldn't be, but that's not a technical problem, it's a perception problem, ZFS won't fix that.
-No more Disk Warrior. The entire data store is self-validating. No bit rot.
ZFS doesn't mandate the storage pool be implemented in any particularly redundant way. If you have just one drive, it's fairly obviously non-redundant. If you add a second drive, it may or may not be a mirror of the first one, depending on how each was added to the pool. Every indication I have seen shows that ZFS checksumming helps detect data integrity errors, and does not implement ECC. It detects block-level silent data corruption, and if the pool is configured just so, the subsystem can reroute things and alert user to service need. If Apples always ship with two drives, it could get clever, but it isn't magical.
-No more volumes and, therefore, no more volume management. ZFS eliminates the whole volume concept. Add a disk to your system and it joins your storage pool. More capacity. Not more management.
For the most part ZFS simplifies it, but not all storage will be wanted in the pool. One shining long term example is removable media (optical and flash). Another is so far, even Sun hasn't figured out how to boot from it, so you will have some volume management still, just adding an external hard disk can be made much much easier than under Linux or Windows.(New uninitialized device detected, add to (cute volume name) or...
-Continuous Data Protection out of the box. Time Machine could give you a view of your data every time you update a file.
ZFS as far as I can see is not a versioned filesystem where every single modification is tracked. It has built-in snapshotting functionality, and therefore makes an easy way to implement time machine backend (or at least offloaded to Sun to sweat the details instead of Apple), perhaps even lower impact at snapshotting time than Time Machine's current implementation, but it won't continuously track changes.
-ITV, or whatever it is going to be called. Multi-GB files that each cost $10-20, that can't be backed up - thanks DRM! - and therefore need a cheap and highly reliable RAID. ITV, two firewire drives, ZFS and you are in business.
Not enough details are available to ascertain how it will work, but while the savvy get the point (my Myth setup separates backend and frontend to have more robust, but noiser measures to protect stuff), by and large mass-market set top boxes get away without redundancy.
-Not to mention the existential pleasure of having great technology that Vista doesn't have. In fact, since consumer technology is driving the enterprise, expect ZFS on Mac to raise the bar for every OS and file system.
ZFS on Mac will likely do little to nothing to raise the bar in the enterprise beyond Solaris doing it. I admit ZFS is the one nugget Sun has brought out for Solaris that has me curious, but OSX's embracing it didn't extend it more. ZFS is among their biggest assets, and they clearly want either revenue or Solaris acceptance from it (hence licensing that precludes it from linux, their primary competitive solution). I think someone was on to something when they discussed the Sun/Apple relationship long term. Solaris, *particularly* thanks to ZFS can perform server-side tasks competently and still has some mindshare. Solaris workstations, however, are largely considered unneeded and counter-productive in ease of use nowadays. Apple has
sleep works great on my R50, except with edgy they botched the radeonfb D2 sleep mode stuff, had to migrate the patch from dapper, which did it right. Of course, they don't load radeonfb by default, so my laptop without my effort would have used 5W instead of 500mW in sleep... But if not using radeon, I bet it'd be great without sweating it.
Can't speak to hibernate, I never need to hibernate and I use a dm-crypt swap partition, so I suspect I wouldn't be able to do it if I wanted too.
I think the pentium 60 mhz was considered about the same as the 100 mhz 486s that came out at the end of the 486 days.. except for dividing floating point numbers of course..
I only recently decommisioned a P60 box that was router in favor of a much more efficient WRT box. Too bad that 286 in the closet I can't possibly conceive a use for anymore...
They are clearly worried about people leveraging linux support to get around protections that prevent playing copied games, and have essentially made the linux support worthless (in true Sony fashion). Sony isn't stupid, and you are too optimistic in the homebrew scenes ability to outproduce large-budget, full work-week efforts by large companies.
I'm evaluating the tips based on them being prescriptions for things to do in interactive shell behavior, since that seems to be the theme. Writing scripts changes the situation to make some tips valuable. My number one tip as a response to these is don't try to be too clever (particularly when the biggest benefit of the approach is to say 'look how clever it is!'). Maybe it's because I don't work in a vacuum and all too many times have been called in to clean up where an administrator tried to do something too complicated for their understanding.
.01s instead of the .09s operation is a bad example. He could have set up a
mkdir -p is a convenience people should be aware of, but telling people to start getting overly creative with the shell expansion behavior is asking for mistakes/trouble. Also, having a mkdirhier script in case the example isn't supported on all shells is an indication that you shouldn't get overly cozy if you are going to be dealing with a lot of different systems/users with different default shells. The amount of time a lot of people take to figure out the 'clever' way in terms of how to phrase the expansion so the shell will expand it right is often longer than just typing the two lines more that the less thought takes. Not saying this isn't useful, but in my experience too many people mess things up too frequently or take too long to think up the expressions to tell them trying to be clever ends up taking more time than they think they are saving.
Change the path instead of the archive is not that dire to do normally, but if you avoid it, to me it's just easier to be in the target directly and use full path to the archive.
On combining commands, I second that ; can be dangerous and && as a default will make the chain more ready to break, but again I say not trying to be so clever as to put all you want on one line. Some things go wrong that aren't reflected in return codes, doing it one at a time let's you think of those. True, though, that the && never assume the first command works, while your fingers may keep moving and hit enter on next command before your brain realizes the command failed, so && may have merit, but then again taking your time may have more merit.
On the quotation thing, true enough, you must understand how quoting works to do remotely complex things, particularly nested circumstances (i.e. ssh to a system to run a command, where the output will be parsed by two shells.)
On the breaking up long lines thing, in a shell script it may be more necessary, but on an interactive command line it could also indicate you are trying too hard to do things in one chunk. I admit sometimes it does get too wide, but particularly less experienced admins should consider if there were a simpler way to do it in smaller chunks they won't screw up.
Grouping commands is important to know, and harmless (better than repeating the same pipe over and over and more powerful).
I will say xargs is way way over-rated. Too many people, particularly dealing with directory trees containing spaces, get into trouble piping the output of find into anything when IFS causes something like "/tmp/Monthly Report" to be parsed as two different files. find has a competent filtering mechanism (-type, -iname, -name, etc...) and it's own -exec. find is well aware of the state of each file. You could assign IFS to try to avoid it, but using find's built-ins where possible alleviates it.
When you are talking about interactive shell operation, picking the
much larger demonstration that would have been useful, but this just makes people mock the example. In any event, this seems like an okay thing to convey, but I dunno if it would've made my top 10.
Probably a more valid point about using awk, and a common trap I do see people stuck in.
On piping cat, that seems like more an annoyance than anything constructive. Some people use the cat | grep construct because it is so unambiguou
Don't use semicolons, use &&.
/, wanted to delete /tmp/root, and you typed cd /tm;rm -rf root. You'd be in trouble, but the && would cause the failed cd to not hose things up.
Actually, this case is a very good example of why && are better as a default over ; to delimit commands on a single line. If you were in
Still, my advice in general would be to avoid stringing commands just for the sake of being clever and run each command serially. More can go wrong than the return code will indicate that output will.