One thing I'll point out is that RDP (using the current Windows clients and servers) is extremely efficient compared to "network-transparent" X. When I use Wireshark to look at what's on the wire, opening a Firefox window on Windows and displaying it to my desktop uses roughly the same bandwidth as X's "network transparent" windowing, but happens much quicker due to latency -- the X client is issuing multiple requests to the X server then *waiting for the response* before continuing on. Furthermore, RDP is transferring ONLY THE CHANGED BYTES, *not* the whole screen, so the notion that RDP transfers the entire screen every time the screen updates on Windows is just plain nonsense. Meanwhile, X is not only transferring the changed bytes, but only doing so after a series of *synchronous* commands. The net result is that the 500ms total turnaround time between my house and my work ends up very painful with "X", while is virtually unnoticeable with RDP.
From a theoretical point of view, it all makes sense. There is a theoretical minimum number of bytes which must be sent to update a window from its old state to its new state. This occurs whether the detection of which bytes need sending is via screen scraping or via the application directly telling the graphics library "these are the bytes that have changed". Recent revisions of RDP have gotten *very* efficient at approaching this theoretical minimum. Standard "X" doesn't even try -- if an application draws a new graphic and tells "X" to display it, X sends the entire new graphic to the remote end, *even if only a few pixels have changed*. (And yes, I know there is such a thing as FreeNX etc., but that's add-ons that are not part of X proper, attempting to work around these performance limits of X).
I guess what I'm saying is that if Wayland chooses to use an RDP-like screen scraping protocol for remote display rather than doing "network-transparent" windows like X, there's no theoretical reason why it cannot be efficient. Pixels are pixels, in the end, and the minimum number of pixels needed to refresh a window are identical whether the pixels are being derived via screen scraping, via screen scraping with hints based on GUI library calls (what RDP does), or via the application telling the display protocol "these are the pixels that have changed". The only difference is that the last requires every application to be written to efficiently tell the display protocol "these are the pixels that have changed" -- and we already know that this isn't so for many major "X" applications, which are far from efficient in that regard.
Do note that my development platform is Fedora 15 / Gnome 3 running KVM VM's of the various target distributions for the product, so I'm clearly familiar enough to use it every day. But I suppose yes and no, because I stopped my investigations into replacing ESXi with KVM or Xen when I ran into a couple of show-stopper issues. The first one was with KVM stability, basically there is a feature we needed that KVM supposedly supports, but KVM regularly kernel panics if we try to use it. I tried at least three different distributions -- Fedora 15, RHEL6, and the latest Ubuntu -- and ran into the same problem with each of them. The second was with distribution Xen support. The only distribution that had a version of Xen new enough to support the functionality we needed was OpenSUSE 11.3, hardly what I would call a stable distribution, and then OpenSUSE 11.4 broke Xen. Any other distribution would have required that we create a new DOM0 kernel and update the Xen runtime utilities and QEMU in DOM0 (note that Xen uses QEMU for its HVM virtualization). *PLUS* write an entirely new virtualization management infrastructure, since libvirtd doesn't support the functionality of Xen that we needed.
Meanwhile ESXi 4.1 Just Works(tm). An attribute that I appreciate more and more as I get older (thus why this is being typed from a Macbook Pro, the only laptop that doesn't annoy me with a palm-surfing trackpad, clunky keyboard, or ridiculously short battery life). So, let's see, where do I want to put several man-months of my time -- into creating actual product that can be sold, or into futzing with Xen? In the end it's a no-brainer, putting the man-months into the product results in a more functional and faster product, whereas putting the man-months into Xen in order to get away from ESXi is just a cheaper product, not a better one -- and price isn't our selling point, functionality and performance is.
A new iscsi volume for each VM is certainly one approach, and actually that's sort of what we're doing with the ESXi VM's -- they have a boot disk on VMFS on an iSCSI volume, and the VM then mounts an iSCSI volume off the SAN for their actual data. And you are certainly correct that it is *technically* feasible to do it with KVM, I have in fact done it -- for a one-off prototype. The pain I endured doing that basically told me that there was no way in BLEEP that this was a supportable solution in the field deployed at customer sites that lack dedicated IT resources.
The ESX console, BTW, isn't necessary for a lot of things if you enable the ssh on your ESXi hosts. vim-cmd is your friend. With an appropriate oem.tgz you can even set up your keys so you can script it from outside. The only time I fire up the VSphere GUI in a VirtualBox Windows VM on my Macbook Pro is when I need to see the actual console (as vs. use rdesktop to a Windows VM or vnc to a Linux VM).
Thing is, neither Xen nor KVM/QEMU are as capable as VMware for the things that VMware is good at. For example, it's typical in the VMware world to create a VMFS volume on an EMC block storage server and use this for virtual machine migration between physical hosts. This works because VMFS is a clustered file system that has some unique attributes that make it good for hosting virtual disk files (it's extent-based, for example, so it will keep the extents of a virtual disk contiguous, meaning that the elevator algorithm for disk management inside your VM actually works and you get close to real-world disk performance). Migrating a virtual machine is literally as easy as stopping it on host A and starting it on host B. I can't do anything of the sort with Xen or KVM/QEMU. Then there's VCenter, which provides a central GUI to manage an entire network's worth of virtual machines.
Don't get me wrong, I despise VSphere. I curse it every time I use it, and I've attempted a Xen or KVM/QEMU migration multiple times to get away from it. I had hoped that the release of Red Hat Enterprise Linux 5 with its fairly up-to-date KVM support, GFS cluster filesystem support, etc., could allow me to replace VSphere in our shop. Unfortunately to get adequate disk performance I ended up having to create LVM volumes to use as VM raw disks, qcow2 on top of any currently-existing Linux filesystem is a disaster. And once you're in the realm of LVM volumes, you're beyond any management tools available for managing KVM - not to mention that the way Linux volume groups currently work, you can't share the same volume group between multiple hosts because Things Go Badly, meaning you can't do the trick that VMware uses to do rapid migration via simply turning off the VM on system A and turning it back on, on system B. (There's some state storage required to do it seamlessly, but again, that's all handled by the shared storage).
So yes, I know Linux (I mean c'mon, I've been using Slashdot since before it had user ID's!) and how to use Xen and KVM/QEMU. But no, they're competitive with VSphere in the enterprise environment only in a limited set of circumstances, and stating that the only reason to use VSphere is "ignorance" is, itself, ignorance.
Indeed, I suspect many of us old-timers will show up now:). Actually, the only reason my UID is so high is that when the Taco introduced the UID system, I was, like, "Puh-leeze. I don't feel like being sorted that way and it won't solve the troll problem anyhow, just give everybody mod points to mod the trolls out of existence." So I commented as "Anonymous Coward" for a while. But that became annoying so I finally broke down and signed up for an ID. Hard to believe that now ID 627 is considered a low ID:).
Don't be so sure that network bandwidth required will be higher than remote X. Displaying a window refresh is displaying a window refresh, in the end -- the number of bytes required to do so has a fixed minimum (i.e., the difference between the old window contents and the new window contents) which doesn't require a "network transparent" protocol to encapsulate, just requires that *something* capture the fact that a certain area has changed and send only that certain area's changes to the remote end. RDP does this quite well, at least as efficiently as "X" does it, and there's no reason to suppose that Wayland could not do it equally well if Wayland's designers put the proper hooks in for a network transparency layer to intercept change events.
I've been using "X" since before modern Windows or Mac OS X existed. My first experience with "X" was on a Sun 4 workstation, running olwm on SunOS. One thing that has been true for every year since I started using "X": The end user experience is terrible. Awful. No application looks like any other application or works the same as any other application, simple things like, e.g., cut and paste, simply don't work the way any sensible end user would expect, and the configuration of the system has been a Deep Dark Dreary Dismal Swamp for the entirety of "X"'s existence. Then when more complete desktop environments like Gnome arrived, they learned altogether all the wrong lessons. Gnome 2 reminded me of Windows 95 if the Soviet Union had not fallen and had decided to clone Windows. You could almost hear the poorly-ground gears gnashing along and the clank of poorly fitting mechanical parts. The whole 'gconf' system, for example, was a dreary re-implementation of the Windows registry which did not even bring with it the redeeming value of replacing all those individual system configuration files that make it impossible to replicate the equivalent of Windows "restore points" for backing out of failed configuration changes. All Gnome 2 managed to do was add yet another layer of mess to the muddled mess that is the Linux user experience. (I'm still reserving judgement on Gnome 3, which appears to be an attempt at cloning Mac OS Lion's UI, but behind the scenes it still clanks).
The only time Unix has *ever* managed to get significant end-user client/desktop share managed to do so only by completely abandoning "X". Look at Android. Do you see "X" anywhere there? Exactly. Look at Mac OS X. Yes, you can run "X" there, but only via a compatibility layer which is deliberately ugly compared to the native UI. Why did these people abandon "X" and go to something different? Once you can answer that question, then, and only then, are you qualified to say "X is the bestest windowing system, like, EVAH!" Until then, you're just blowing hot air.
Finally, regarding network transparency and "X": Uhm, have you used Microsoft's RDP recently? It makes any network transparency you get from "X" look sad and dated. Even the *sound* from the remote end comes out on your local desktop! And if you want to share files between your local desktop and the remote system you're logged into, just set up file sharing in your RDP session, and presto, it pops out on the other end as a network share automatically when you log in to the remote end. And your desktop resizes itself to your *LOCAL* screen size, instead of being hard-wired to the *REMOTE* screen size like with VNC. And the performance is a quantum leap over the sad pathetic laggy excuse for VNC that is Vino on Gnome. Anybody who claims network transparency as an advantage of "X" hasn't used a modern RDP client to a modern Windows system. What people want is to access their desktop whether they're local or remote. RDP is currently the best way of doing that on the planet, period. Any advantage "X" ever had in this area was in the 20th century. Given that, why bother with all the overhead and mess of "X"? Why not just take some popular GUI library and make that talk directly to hardware (or to a remote display like RDP) via a light abstraction layer? We could call it something novel, like, say, "Mac OS X". And I'm sure it'd sell like hotcakes.
Utter nonsense. I've had articles that I follow from time to time deleted for "non-notability" even if they were well-sourced and had verifiable information. If the person or subject they were about was incomprehensible to some cheeto-munching "editor" in his mommy's basement who decided that an article that had been up for literally years wasn't "notable" because nobody had edited it in years and only a few dozen people had even *looked* at it in that time, zap. End of article. A notability delete tag would get added, and because we're talking about an obscure topic in the history of mathematics of interest only to mathematicians, few of whom bother checking Wikipedia on a regular basis to check for things like delete tags, *gone*. Blam bam thank you m'am. History deleted. Down the memory hole. Who needs history anyhow? We got articles about recently dead crack-smoking singers to update, after all!
Wikipedia worked better when it was an actual anarchy as vs. this current hyper-moderated BS. Sure, popular pages got defaced regularly back in those days, but those of us who had info to contribute on actual scholarly topics didn't have to worry about "notability" back in those days, and the popular pages eventually got edited or reverted back into some semblance of order. Now... eh. I'm not going to bother.
Sayyyyy.... why doesn't someone start "RealPedia" which is Wikipedia as it was back before all the nonsense? Hmm...
I am posting this from a mid-2010 MBP running Mac OS Lion. Been stable as a rock. Certainly no kernel panics. Everything Just Works(tm), just the way it is supposed to. I *did* take the precaution of re-installing from scratch -- my MacOS install dated all the way back to Tiger (been updated every year or two as new MacOS versions come out or I get a new Mac), and was starting to get a bit unstable due to accumulated cruft. Gave me an excuse to upgrade to that new 7200 rpm 750gb hard drive anyhow:).
Bob, I've written backup software before (including hard-disk based backup) so I know the level of complexity involved. You're right, it's not *that* difficult. I estimate roughly 24 man-months of effort would be involved in the totality what I'd like to see for "Time Machine For Linux" complete with nifty GUI for time travelling, but the core engine would be fairly simple, basically six man-months of effort. The main issue is that I have a more-than-full-time job that pays very well, and thus little spare time. Thus why I am so annoyed by the backup situation on Linux (and by the fact that Linux geeks, in full-on xkcd 619 mode, fail to see why it's a problem), but thus far not been annoyed enough to do anything about it myself. That is especially true since I *do* run RAID and do backups via rsync on my desktop and in fact have had a drive die and all I did was pull out the old one, put in the new one, put RAID volumes on it, then added it to the mirror and sat back and watched the RAID rebuild get me back fully mirrored again... but that's not going to work if I want to run Linux on a laptop, since laptops don't have multiple drives to do RAID, and basically you have nothing bootable on a Linux laptop if the main hard drive goes. Which is why my laptop is a Macbook Pro... I had a hard drive die and I re-installed MacOS on the new drive, at the end of the re-install it asked me "Do you want to restore from your Time Machine backup?", I answered "Yes", and it Just Worked, leaving me at the end of the install with my laptop exactly as it was prior the crash, complete with all configuration and all software. You can't say that about any Linux backup solution. Yet.
Em, see above. BackupPC *does* require an administrator to figure out what to backup where and to manage restores upon system crashes. It is exactly NOT what a desktop home user can use to backup and restore his/her own system without an expert handy, and is in no way equivalent to Time Machine. XKCD 619. Linux geeks. Sigh.
Bob, I've used rsync, I've used tar with timestamps, I've used BRU (duh), I've used pretty much everything out there. None of them match up one whit to Time Machine on the ease-of-use (where you plug the USB drive in, MacOS asks you "Do you want to use this disk for backup?", you click YES, and it Just Works) -- and, more importantly, EASE OF RESTORE -- scale. Indeed, most backup solutions appear to be write-only -- you can create backups, but getting anything back from them is a major PITA. For example, you can't ask typical backup solutions to restore the last full plus all incrementals since that last full, you have to manually install the last full, then manually install each of the incrementals since the last full... meanwhile, if you have to re-install a Mac after a disk crash, it asks you at install time whether you want to restore from your Time Machine volume, you answer "Yes", and it just does it. I've done it. My machine was back to where it was prior to the hard drive getting the click-o-death, including the all-important source code files that I'd edited the previous day and was afraid were lost.
So anyhow, for backup here's my basic criteria:
1) Bootable backup drive so you just boot to the USB backup drive and restore if you have a hard drive crash. I can create bootable drives in my sleep. I can create bootable restore disks based upon a running Linux system in my sleep. I've done it multiple times for multiple employers, there's no brain surgery involved, just create a boot RAMDISK with the proper stuff in it by picking and choosing from what's installed on your current system and extracting required info for recreating your current system from your current system. There's no reason why restore after a hard drive crash should be such a PITA. 2) Better incremental backup functionality than Time Machine. Right now, if you have a VMware disk file, Time Machine will try to backup the entire file. It should be possible to back up only the "chunks" that have changed since the last full backup of the file, then re-assemble to a specified time point on restore. 3) *CONSISTENCY*. If you back up a VMware or KVM disk file while it's in use, you get an inconsistent (and often corrupted) filesystem (even with logging filesystems) because you're backing up the front of the file at a different time from the back of the file, thereby violating a fundamental assumption of even logging filesystems (that all blocks on a disk are consistent as of a given point in time). Same applies to database files as used by MySQL or PostGres. The only way to do a consistent backup with current Linux filesystems is to create a LVM snapshot volume as of the start of the backup and backup the snapshot. BTRFS will supposedly allow doing that at the filesystem level, which will be far faster (I can get into details of why writes get so slow with LVM snapshots, especially if your snapshot volume happens to be on a USB hard drive, but go Google it yourself). 4) Ease of use. It shouldn't require a degree in Backupology to work. Once the program is installed and running in your GUI environment, plugging a USB drive in should pop up a query as to whether you want to use it for backup (if you've never plugged it in to this system before), with a warning that saying "Yes" will result in the drive being wiped out and reformatted for use as backup (since it will need to have LVM volumes put onto it for use in snapshotting the rest of your system -- which, for a desktop Linux system installed with defaults, will be on LVM already). From thence onward, it should Just Work, such that even if you rotate backup disks in order to maintain offsite backups, each of the backup disks should have a complete backup of your system as of a point in time. For that matter, it could even have a plugin for the Gnome VFS (or KDE equivalent) so you could browse in time in a manner integrated with the rest of your desktop.
Needless to say, I'm talking about *desktop* Linux systems here, which is why it hasn't been done -- Linux geeks general
So, Rary, what is your backup policy? Do you do daily full backups rotated off-site, or do you rely on a single backup that is overwritten every day? Have you tested your restore mechanism to make sure that your backups can get you back to where you were the previous evening? If you lose a file, do you have a mechanism in place for retrieving it from backups? What if the file isn't on your most recent backup, do you have some way to retrieve it from a past backup? What mechanism do you have in place for validating that Windows updates do not break critical software on your system? Are you using a user ID that has install permissions in system folders? Do you have Javascript enabled or disabled in your browser? Which antivirus are you using? Which firewall program are you using, and what firewall exceptions are needed in that firewall for the software you require for your work to run? What anti-spyware program are you using, and are you *sure* you don't have spyware installed on your Windows system?
If you're using Windows at work at even small companies, you're using AD, where all these configuration decisions are made by the network administrator team and your desktop is pretty much locked down, with the exact validated set of software and OS patches needed to run, and you don't have administrative access to fubar the system. The usual exception is if you're a developer, where you need to regularly blow things away to test your software. Even there, you're better off using VMware or KVM rather than doing it on actual physical hardware.
BTW, Linux isn't much better here, other than that it usually comes pre-configured with defaults that work for most folks for everything except backups. I have glumly come to the conclusion that if I want something equivalent to or better than MacOS's Time Machine on Linux for doing time-based incremental backups, I'm going to have to write it myself, and it's going to have to rely on LVM's snapshotting mechanism to do a consistent backup until BTRFS is ready. Yay team. At least we have SQLite nowadays, not like when I designed BRU Server back in the late 90's...
That said, ChromeOS isn't useful for me. It might be useful for my mother, though. All she does is read email and browse the Internet. The only reason her machine, an HP laptop, isn't a reeking virus-infested spyware-riddled useless pile of plastic is because my brother does all the administrative stuff for her. Otherwise it'd be useless.
All the latest video cameras are either POE or WiFi. We currently have around 50 WiFi cameras in our facility and roughly 200 POE cameras (we do camera validation with VDMR venders). Composite-over-coax cameras are not used for any installation that has more than four cameras nowadays because it doesn't scale -- modern-day legal requirements pretty much require you to store video data for *all* the cameras for a specified amount of time, you can't do like the old days where you just flipped between cameras recording snippets to a VCR tape. Try doing that in today's legal environment and someone gets raped while your cameras aren't recording that area, and you're going to end up with one honkin' big negligence lawsuit against you. Regarding where WiFi cameras are used vs. POE cameras, by and large it depends upon access to power and data. Where wires can be run, POE is preferred for security purposes. If the integrator must instead suck power from, say, the emergency exit light's power source (say we're talking about a fire escape stairwell where it's virtually impossible to run new wires due to the physical firewall requirements), that's where a WiFi camera gets plunked on top of the EXIT sign or fire escape light and piggybacks on that power.
Disclaimer: I work for a vendor of video surveillance appliances.
When personal computers came out, IT said "personal computers are toys and useless for real work, we do not allow them in our facility." When the first commercial Linux arrived in late 1995, I heard IT say "Linux is a toy and useless for real work, we do not allow it in our facility." Now I read in this very thread people saying "iPads are toys and useless for real work, we do not allow them." Hint to IT: It didn't work when you said that in 1980, it didn't work when you said that in 1995, and it won't work when you say that today.
I've heard all the excuses over the past 30 years over why IT can't allow the latest technology, and in the end they all ram up against reality. Mordac the Preventer of Information Services may have short-term victories, but in the end the wheels of progress grind him up. Reality simply *IS*. You aren't going to stop the executives from bringing in those things because they outrank you and your rear end will be out on the street if you try to stop them, not to mention that if you don't provide a secure wireless network capable of handling the iPads and other wireless devices that people want to use in your facility, you're going to end up with wildcat devices, often in the hands of untouchables -- people you can't touch, because they outrank you / are mission critical to the company / are close personal friends with the CEO / whatever. I've seen this dynamic -- IT trying to stop new technology from entering the workplace, and being bypassed -- so many times over the years, that you'd think IT would get a clue and get ahead of the technology curve rather than trying to downplay the new technology as "just a toy and useless for real work." Yet reading the comments on this article I see IT people doing the same thing that didn't work in 1995, that didn't work in 1980, that won't work today -- trying to keep technology they don't understand / don't like / have no personal use for themselves out of the workplace.
Hint: You might as well start trying to figure out how to make your environment work for ubiquitous wireless devices, because it is *not* a "fad" that's going away. An iPad isn't a substitute for a desktop computer, just as a desktop computer isn't a substitute for a mainframe, but clearly people are finding the things to be useful for *something* if they're wanting it on the work network, and it's not your job as IT to tell them that no, it's *not* useful (when clearly the reality is that it darn well *is* useful for something, even if you don't understand what), it's your job to accept that reality and figure out some way to get the things on your network in a secure and reasonably speedy fashion. Because it will happen regardless -- so you might as well do it right, instead of the futile fight against insecure wildcat access points in the hands of untouchables that will otherwise happen.
I am on a D-STAR discussion list. Apparently the issue is that D-STAR has not previously been an allowed digital mode in France, and there is an old time neanderthal HF ham radio guy in their radio regulatory department (the type of guy who believes ham radio died the moment there was no longer a requirement to build your own HF morse code transceiver in order to get a ham license) who does not believe that *any* digital modes should be allowed who is now in a position to block the adoption of new digital modes. Check out this list of a large number of digital modes that are banned in France (note that this page is in French, but if you are American you should be able to read the huge number of disallowed modes, and the much smaller number of allowed modes at the end). In any event, the whole "can be routed over the Internet" thingy is a base canard being used by this old-school guy to disallow digital modes, rather than the real reason, so... (shrug).
1) Tesla's direct-to-consumer model is illegal in numerous states, which require all new automobiles to be sold via dealers with full service departments in order to handle warranty claims. Granted, there's ways around that, such as the dealer merely being a delivery mechanism rather than themselves having an inventory of the cars, but you still end up needing dealers and the infrastructure for dealing with dealers.
2) The auto industry is an incredibly capital-intensive industry, it on average takes $2B to create an all-new car from scratch. Tesla doesn't have some of those costs (like the costs of emissions certification and engine design), but has additional new costs (the costs of battery design and electric motor design). Even with the money they just raised, by my counting they're still some $1.5B short of the amount of money needed to mass-produce a competitive design.
3) Manufacturing is *HARD*. Tesla has a lot of design geeks, but very few manufacturing engineers and technicians with automotive industry experience. Manufacturing is where most of these plans fall astray. Tesla now has a gigantic manufacturing facility, thanks to Toyota, but has to fill it with the tooling and processes to mass-produce their car, and that is *not* an easy chore.
In short, add me to the list of those who are dubious. By the time Tesla gets the glitches out and figures out how to manufacture their car, competitors from Nissan and GM will be available for less money. Competing with entrenched incumbents with the same basic product is *never* a recipe for success in today's "free market" environment, which highly favors incumbents in both the financial marketplace and in the supplier marketplace (where most of the suppliers are captive to the incumbents and will supply the incumbents before they supply you, and will supply the incumbents for less money than they'll supply you -- a major problem when critical components in short supply are required by both yourself and the incumbent). I've run into these issues before with manufacturing startups I've worked for, and the solution was either to run for a niche market where the incumbent was not competitive (which usually ended up with the company being bought out by an incumbent if the niche proved profitable) or going out of business (the usual result). If Tesla had started shipping their mass market car two years ago, they would have a chance. Right now, against the Volt and Leaf... uhm.
The wild card: Tesla's battery technology. If Tesla turns into a battery supplier to the auto makers rather than an automaker themselves, they could survive. As an automaker? Color me dubious... this sounds awfully lot like the DeLorean situation, makes you wonder which Tesla founder is going to be discovered shipping crates of cocaine in order to finance parts inventory, hmm.
So you're saying that our politicians were appointed by an evil tyrant, rather than elected by the majority of people in their state or district? Hmm... gosh, I could have *sworn* that I actually *voted* for somebody for President a couple of years ago, and (gasp) the person with the majority of votes WON OFFICE. The fact that Americans consistently vote for the most corrupt politicians, the ones most effective at collecting bribes err campaign contributions... well, what can I say? In a democracy, people get the kind of government they want -- and deserve. Alas.
I am so gratified to learn that "the government" was appointed by evil dictators, rather than selected by We The People to handle our interests! Why, the notion that every single one of the folks in Congress were appointed by evil dictators rather than selected by the majority of voters in his or her state or district explains everything, everything I say, about why America is in the grips of tyranny!
Or it could be that America gets the government it wants -- and deserves. Whatevah.
So "the government" is an alien and foreign dictatorship imposed on America, rather than a bunch of folks that We The People voted into office to represent the interests of We The People? Gosh, you learn something new every day!
Have to agree, if I were a Fortune 500 company I would use Google mail and apps pretty much about the same time that the Earth froze over. The legal consequences alone are astounding in their repercussions. How do you enforce data retention policies intended to keep documents as long as legally required but not one second longer? Respond to legal discovery? Freeze mailboxes relevant to a specific legal action in order to preserve evidence, while not locking out the user who needs to get his *current* emails? Locate all documents containing references to the words "Acme Inc.", without individually logging onto every user's Google account? Do you understand just how many discovery subpoenas the typical Fortune 500 company receives in the course of a day, and what the repercussions are for not being able to respond to them?
Then there's privacy, which will be a huge issue with major healthcare companies and banking institutions who may find that customer privacy laws basically prohibit them from outsourcing any data that may contain any customer-identifiable data (and how would you enforce "no customer-identifiable data" in email, which by definition may be used to communicate with customers?), etc. Frankly, if I were a major company or in a health care field, I'd outsource my email to Google, well, never.
That said, it decidedly makes sense for small businesses to use Google Apps rather than Microsoft "We eat your emails!" Exchange. My own employer does so. But we aren't getting sued every day like, say, Google (heh)...
Folks looking for all these classes, sessions, certificates, and training programs are looking for folks who are good at lying on resumes, by and large. Tells you what the work environment is like -- a dog eat dog back-stabbing cesspool of liars and braggarts. Those of us with a long history of what, for a better word, I'll call getting s**t done, avoid such places like the plague, which is why those places whine and complain that they can't find anybody who knows anything who's willing to work for them.
Median salaries across the board shrunk last year. If IT salaries are merely stagnant, that's still better than everybody else in this cruddy economy. I'm happy to be making the exact same thing I made last year. Heck, I'm happy I have a job right now, though I'm not sure how much longer that's going to last. Given what's happening elsewhere in the economy, treading water is a major win. But I guess there just has to be whiners in any profession who will take any excuse to complain...
The reality is that you most likely won't be fined. When I was working Census, if we could not get information from you personally, we did a number of things. The first stop was the county courthouse to pull the property information. If the address of the owner was different from the address of the property, we assumed that it was a rental property, and called that person (likely the landlord) and identified ourself as a Census worker and asked who was living at the property on April 1 or for the name of the property manager if the property manager rather than they had the information. If the address of the owner was the same as the address of the property, we then went to the neighbors and asked them, "hey, I'm having trouble getting in touch with Joe Schmuck next door, you know him?" and get any information we could about him, where he worked, where we might be able to directly contact him. There was one small town, I walked into the feed store and asked them about the dude who lived next door where I'd gotten no answer. Turned out the schmuck was infamous in the area for his involvement with various right-wing "militia" activities and a standoff he'd been involved in a few years back regarding a highway project where they eventually routed the highway around his fertilizer warehouse property because they didn't want to make him a martyr. Anyhow, these good ole' boys just *loved* talking about that schmuck, he was the best topic of gossip they'd had for *years*. They did warn me that he would likely start shooting if I came to the house while he was there. But I went there while he was at work and got his boy toy instead and got all the information that I actually needed to validate what the original census taker had originally recorded (probably from interviewing the good ole' boys at the feed store too, heh!), which was just the names and race actually.
So what happened if you were a hermit and your neighbors didn't know you and etc.? At that point I was instructed to turn it over to my supervisor, who would then turn in a federal records request that had to go before a special court and resulted in a court order that allowed the Census to pull Social Security records, IRS income tax records, etc. But that never happened during the three months I worked Census, we always got our man, woman, or child:).
So in the end, all you do when you refuse to answer the Census is cost the taxpayers money. A *LOT* of money. I was getting basically $10/hour to go after these "difficult" cases once you added in my mileage charges, and that was in 1995 dollars. If it had to be escalated up to a supervisor and a records request, it cost thousands upon thousands of taxpayer dollars to go through that process. In the end, the government already has all the information that the Census requests... it just costs a lot more money to pull it together from all those vast databases than just asking you on that little form. So you might as well just fill out the friggin' form... it's not as if you're telling the government anything that it doesn't already know, after all. You're just saving taxpayer money, that's pretty much it.
Really? Care to give me a pointer to that Supreme Court decision? The only decisions I'm aware of are regarding use of racial classification as an employment or educational enrollment qualification, and even there, the gathering of racial classification information was not outlawed -- just its use for employment or enrollment decisions. The Supreme Court has repeatedly upheld the Voting Rights Act of 1965 and its requirement that the Census gather racial information in order to apportion districts in order to assure representation for minority populations.
Slashdot Mirror
One thing I'll point out is that RDP (using the current Windows clients and servers) is extremely efficient compared to "network-transparent" X. When I use Wireshark to look at what's on the wire, opening a Firefox window on Windows and displaying it to my desktop uses roughly the same bandwidth as X's "network transparent" windowing, but happens much quicker due to latency -- the X client is issuing multiple requests to the X server then *waiting for the response* before continuing on. Furthermore, RDP is transferring ONLY THE CHANGED BYTES, *not* the whole screen, so the notion that RDP transfers the entire screen every time the screen updates on Windows is just plain nonsense. Meanwhile, X is not only transferring the changed bytes, but only doing so after a series of *synchronous* commands. The net result is that the 500ms total turnaround time between my house and my work ends up very painful with "X", while is virtually unnoticeable with RDP.
From a theoretical point of view, it all makes sense. There is a theoretical minimum number of bytes which must be sent to update a window from its old state to its new state. This occurs whether the detection of which bytes need sending is via screen scraping or via the application directly telling the graphics library "these are the bytes that have changed". Recent revisions of RDP have gotten *very* efficient at approaching this theoretical minimum. Standard "X" doesn't even try -- if an application draws a new graphic and tells "X" to display it, X sends the entire new graphic to the remote end, *even if only a few pixels have changed*. (And yes, I know there is such a thing as FreeNX etc., but that's add-ons that are not part of X proper, attempting to work around these performance limits of X).
I guess what I'm saying is that if Wayland chooses to use an RDP-like screen scraping protocol for remote display rather than doing "network-transparent" windows like X, there's no theoretical reason why it cannot be efficient. Pixels are pixels, in the end, and the minimum number of pixels needed to refresh a window are identical whether the pixels are being derived via screen scraping, via screen scraping with hints based on GUI library calls (what RDP does), or via the application telling the display protocol "these are the pixels that have changed". The only difference is that the last requires every application to be written to efficiently tell the display protocol "these are the pixels that have changed" -- and we already know that this isn't so for many major "X" applications, which are far from efficient in that regard.
Do note that my development platform is Fedora 15 / Gnome 3 running KVM VM's of the various target distributions for the product, so I'm clearly familiar enough to use it every day. But I suppose yes and no, because I stopped my investigations into replacing ESXi with KVM or Xen when I ran into a couple of show-stopper issues. The first one was with KVM stability, basically there is a feature we needed that KVM supposedly supports, but KVM regularly kernel panics if we try to use it. I tried at least three different distributions -- Fedora 15, RHEL6, and the latest Ubuntu -- and ran into the same problem with each of them. The second was with distribution Xen support. The only distribution that had a version of Xen new enough to support the functionality we needed was OpenSUSE 11.3, hardly what I would call a stable distribution, and then OpenSUSE 11.4 broke Xen. Any other distribution would have required that we create a new DOM0 kernel and update the Xen runtime utilities and QEMU in DOM0 (note that Xen uses QEMU for its HVM virtualization). *PLUS* write an entirely new virtualization management infrastructure, since libvirtd doesn't support the functionality of Xen that we needed.
Meanwhile ESXi 4.1 Just Works(tm). An attribute that I appreciate more and more as I get older (thus why this is being typed from a Macbook Pro, the only laptop that doesn't annoy me with a palm-surfing trackpad, clunky keyboard, or ridiculously short battery life). So, let's see, where do I want to put several man-months of my time -- into creating actual product that can be sold, or into futzing with Xen? In the end it's a no-brainer, putting the man-months into the product results in a more functional and faster product, whereas putting the man-months into Xen in order to get away from ESXi is just a cheaper product, not a better one -- and price isn't our selling point, functionality and performance is.
A new iscsi volume for each VM is certainly one approach, and actually that's sort of what we're doing with the ESXi VM's -- they have a boot disk on VMFS on an iSCSI volume, and the VM then mounts an iSCSI volume off the SAN for their actual data. And you are certainly correct that it is *technically* feasible to do it with KVM, I have in fact done it -- for a one-off prototype. The pain I endured doing that basically told me that there was no way in BLEEP that this was a supportable solution in the field deployed at customer sites that lack dedicated IT resources.
The ESX console, BTW, isn't necessary for a lot of things if you enable the ssh on your ESXi hosts. vim-cmd is your friend. With an appropriate oem.tgz you can even set up your keys so you can script it from outside. The only time I fire up the VSphere GUI in a VirtualBox Windows VM on my Macbook Pro is when I need to see the actual console (as vs. use rdesktop to a Windows VM or vnc to a Linux VM).
Thing is, neither Xen nor KVM/QEMU are as capable as VMware for the things that VMware is good at. For example, it's typical in the VMware world to create a VMFS volume on an EMC block storage server and use this for virtual machine migration between physical hosts. This works because VMFS is a clustered file system that has some unique attributes that make it good for hosting virtual disk files (it's extent-based, for example, so it will keep the extents of a virtual disk contiguous, meaning that the elevator algorithm for disk management inside your VM actually works and you get close to real-world disk performance). Migrating a virtual machine is literally as easy as stopping it on host A and starting it on host B. I can't do anything of the sort with Xen or KVM/QEMU. Then there's VCenter, which provides a central GUI to manage an entire network's worth of virtual machines.
Don't get me wrong, I despise VSphere. I curse it every time I use it, and I've attempted a Xen or KVM/QEMU migration multiple times to get away from it. I had hoped that the release of Red Hat Enterprise Linux 5 with its fairly up-to-date KVM support, GFS cluster filesystem support, etc., could allow me to replace VSphere in our shop. Unfortunately to get adequate disk performance I ended up having to create LVM volumes to use as VM raw disks, qcow2 on top of any currently-existing Linux filesystem is a disaster. And once you're in the realm of LVM volumes, you're beyond any management tools available for managing KVM - not to mention that the way Linux volume groups currently work, you can't share the same volume group between multiple hosts because Things Go Badly, meaning you can't do the trick that VMware uses to do rapid migration via simply turning off the VM on system A and turning it back on, on system B. (There's some state storage required to do it seamlessly, but again, that's all handled by the shared storage).
So yes, I know Linux (I mean c'mon, I've been using Slashdot since before it had user ID's!) and how to use Xen and KVM/QEMU. But no, they're competitive with VSphere in the enterprise environment only in a limited set of circumstances, and stating that the only reason to use VSphere is "ignorance" is, itself, ignorance.
Indeed, I suspect many of us old-timers will show up now :). Actually, the only reason my UID is so high is that when the Taco introduced the UID system, I was, like, "Puh-leeze. I don't feel like being sorted that way and it won't solve the troll problem anyhow, just give everybody mod points to mod the trolls out of existence." So I commented as "Anonymous Coward" for a while. But that became annoying so I finally broke down and signed up for an ID. Hard to believe that now ID 627 is considered a low ID :).
Don't be so sure that network bandwidth required will be higher than remote X. Displaying a window refresh is displaying a window refresh, in the end -- the number of bytes required to do so has a fixed minimum (i.e., the difference between the old window contents and the new window contents) which doesn't require a "network transparent" protocol to encapsulate, just requires that *something* capture the fact that a certain area has changed and send only that certain area's changes to the remote end. RDP does this quite well, at least as efficiently as "X" does it, and there's no reason to suppose that Wayland could not do it equally well if Wayland's designers put the proper hooks in for a network transparency layer to intercept change events.
I've been using "X" since before modern Windows or Mac OS X existed. My first experience with "X" was on a Sun 4 workstation, running olwm on SunOS. One thing that has been true for every year since I started using "X": The end user experience is terrible. Awful. No application looks like any other application or works the same as any other application, simple things like, e.g., cut and paste, simply don't work the way any sensible end user would expect, and the configuration of the system has been a Deep Dark Dreary Dismal Swamp for the entirety of "X"'s existence. Then when more complete desktop environments like Gnome arrived, they learned altogether all the wrong lessons. Gnome 2 reminded me of Windows 95 if the Soviet Union had not fallen and had decided to clone Windows. You could almost hear the poorly-ground gears gnashing along and the clank of poorly fitting mechanical parts. The whole 'gconf' system, for example, was a dreary re-implementation of the Windows registry which did not even bring with it the redeeming value of replacing all those individual system configuration files that make it impossible to replicate the equivalent of Windows "restore points" for backing out of failed configuration changes. All Gnome 2 managed to do was add yet another layer of mess to the muddled mess that is the Linux user experience. (I'm still reserving judgement on Gnome 3, which appears to be an attempt at cloning Mac OS Lion's UI, but behind the scenes it still clanks).
The only time Unix has *ever* managed to get significant end-user client/desktop share managed to do so only by completely abandoning "X". Look at Android. Do you see "X" anywhere there? Exactly. Look at Mac OS X. Yes, you can run "X" there, but only via a compatibility layer which is deliberately ugly compared to the native UI. Why did these people abandon "X" and go to something different? Once you can answer that question, then, and only then, are you qualified to say "X is the bestest windowing system, like, EVAH!" Until then, you're just blowing hot air.
Finally, regarding network transparency and "X": Uhm, have you used Microsoft's RDP recently? It makes any network transparency you get from "X" look sad and dated. Even the *sound* from the remote end comes out on your local desktop! And if you want to share files between your local desktop and the remote system you're logged into, just set up file sharing in your RDP session, and presto, it pops out on the other end as a network share automatically when you log in to the remote end. And your desktop resizes itself to your *LOCAL* screen size, instead of being hard-wired to the *REMOTE* screen size like with VNC. And the performance is a quantum leap over the sad pathetic laggy excuse for VNC that is Vino on Gnome. Anybody who claims network transparency as an advantage of "X" hasn't used a modern RDP client to a modern Windows system. What people want is to access their desktop whether they're local or remote. RDP is currently the best way of doing that on the planet, period. Any advantage "X" ever had in this area was in the 20th century. Given that, why bother with all the overhead and mess of "X"? Why not just take some popular GUI library and make that talk directly to hardware (or to a remote display like RDP) via a light abstraction layer? We could call it something novel, like, say, "Mac OS X". And I'm sure it'd sell like hotcakes.
Utter nonsense. I've had articles that I follow from time to time deleted for "non-notability" even if they were well-sourced and had verifiable information. If the person or subject they were about was incomprehensible to some cheeto-munching "editor" in his mommy's basement who decided that an article that had been up for literally years wasn't "notable" because nobody had edited it in years and only a few dozen people had even *looked* at it in that time, zap. End of article. A notability delete tag would get added, and because we're talking about an obscure topic in the history of mathematics of interest only to mathematicians, few of whom bother checking Wikipedia on a regular basis to check for things like delete tags, *gone*. Blam bam thank you m'am. History deleted. Down the memory hole. Who needs history anyhow? We got articles about recently dead crack-smoking singers to update, after all!
Wikipedia worked better when it was an actual anarchy as vs. this current hyper-moderated BS. Sure, popular pages got defaced regularly back in those days, but those of us who had info to contribute on actual scholarly topics didn't have to worry about "notability" back in those days, and the popular pages eventually got edited or reverted back into some semblance of order. Now... eh. I'm not going to bother.
Sayyyyy.... why doesn't someone start "RealPedia" which is Wikipedia as it was back before all the nonsense? Hmm...
I am posting this from a mid-2010 MBP running Mac OS Lion. Been stable as a rock. Certainly no kernel panics. Everything Just Works(tm), just the way it is supposed to. I *did* take the precaution of re-installing from scratch -- my MacOS install dated all the way back to Tiger (been updated every year or two as new MacOS versions come out or I get a new Mac), and was starting to get a bit unstable due to accumulated cruft. Gave me an excuse to upgrade to that new 7200 rpm 750gb hard drive anyhow :).
Bob, I've written backup software before (including hard-disk based backup) so I know the level of complexity involved. You're right, it's not *that* difficult. I estimate roughly 24 man-months of effort would be involved in the totality what I'd like to see for "Time Machine For Linux" complete with nifty GUI for time travelling, but the core engine would be fairly simple, basically six man-months of effort. The main issue is that I have a more-than-full-time job that pays very well, and thus little spare time. Thus why I am so annoyed by the backup situation on Linux (and by the fact that Linux geeks, in full-on xkcd 619 mode, fail to see why it's a problem), but thus far not been annoyed enough to do anything about it myself. That is especially true since I *do* run RAID and do backups via rsync on my desktop and in fact have had a drive die and all I did was pull out the old one, put in the new one, put RAID volumes on it, then added it to the mirror and sat back and watched the RAID rebuild get me back fully mirrored again... but that's not going to work if I want to run Linux on a laptop, since laptops don't have multiple drives to do RAID, and basically you have nothing bootable on a Linux laptop if the main hard drive goes. Which is why my laptop is a Macbook Pro... I had a hard drive die and I re-installed MacOS on the new drive, at the end of the re-install it asked me "Do you want to restore from your Time Machine backup?", I answered "Yes", and it Just Worked, leaving me at the end of the install with my laptop exactly as it was prior the crash, complete with all configuration and all software. You can't say that about any Linux backup solution. Yet.
Em, see above. BackupPC *does* require an administrator to figure out what to backup where and to manage restores upon system crashes. It is exactly NOT what a desktop home user can use to backup and restore his/her own system without an expert handy, and is in no way equivalent to Time Machine. XKCD 619. Linux geeks. Sigh.
Bob, I've used rsync, I've used tar with timestamps, I've used BRU (duh), I've used pretty much everything out there. None of them match up one whit to Time Machine on the ease-of-use (where you plug the USB drive in, MacOS asks you "Do you want to use this disk for backup?", you click YES, and it Just Works) -- and, more importantly, EASE OF RESTORE -- scale. Indeed, most backup solutions appear to be write-only -- you can create backups, but getting anything back from them is a major PITA. For example, you can't ask typical backup solutions to restore the last full plus all incrementals since that last full, you have to manually install the last full, then manually install each of the incrementals since the last full... meanwhile, if you have to re-install a Mac after a disk crash, it asks you at install time whether you want to restore from your Time Machine volume, you answer "Yes", and it just does it. I've done it. My machine was back to where it was prior to the hard drive getting the click-o-death, including the all-important source code files that I'd edited the previous day and was afraid were lost.
So anyhow, for backup here's my basic criteria:
1) Bootable backup drive so you just boot to the USB backup drive and restore if you have a hard drive crash. I can create bootable drives in my sleep. I can create bootable restore disks based upon a running Linux system in my sleep. I've done it multiple times for multiple employers, there's no brain surgery involved, just create a boot RAMDISK with the proper stuff in it by picking and choosing from what's installed on your current system and extracting required info for recreating your current system from your current system. There's no reason why restore after a hard drive crash should be such a PITA.
2) Better incremental backup functionality than Time Machine. Right now, if you have a VMware disk file, Time Machine will try to backup the entire file. It should be possible to back up only the "chunks" that have changed since the last full backup of the file, then re-assemble to a specified time point on restore.
3) *CONSISTENCY*. If you back up a VMware or KVM disk file while it's in use, you get an inconsistent (and often corrupted) filesystem (even with logging filesystems) because you're backing up the front of the file at a different time from the back of the file, thereby violating a fundamental assumption of even logging filesystems (that all blocks on a disk are consistent as of a given point in time). Same applies to database files as used by MySQL or PostGres. The only way to do a consistent backup with current Linux filesystems is to create a LVM snapshot volume as of the start of the backup and backup the snapshot. BTRFS will supposedly allow doing that at the filesystem level, which will be far faster (I can get into details of why writes get so slow with LVM snapshots, especially if your snapshot volume happens to be on a USB hard drive, but go Google it yourself).
4) Ease of use. It shouldn't require a degree in Backupology to work. Once the program is installed and running in your GUI environment, plugging a USB drive in should pop up a query as to whether you want to use it for backup (if you've never plugged it in to this system before), with a warning that saying "Yes" will result in the drive being wiped out and reformatted for use as backup (since it will need to have LVM volumes put onto it for use in snapshotting the rest of your system -- which, for a desktop Linux system installed with defaults, will be on LVM already). From thence onward, it should Just Work, such that even if you rotate backup disks in order to maintain offsite backups, each of the backup disks should have a complete backup of your system as of a point in time. For that matter, it could even have a plugin for the Gnome VFS (or KDE equivalent) so you could browse in time in a manner integrated with the rest of your desktop.
Needless to say, I'm talking about *desktop* Linux systems here, which is why it hasn't been done -- Linux geeks general
So, Rary, what is your backup policy? Do you do daily full backups rotated off-site, or do you rely on a single backup that is overwritten every day? Have you tested your restore mechanism to make sure that your backups can get you back to where you were the previous evening? If you lose a file, do you have a mechanism in place for retrieving it from backups? What if the file isn't on your most recent backup, do you have some way to retrieve it from a past backup? What mechanism do you have in place for validating that Windows updates do not break critical software on your system? Are you using a user ID that has install permissions in system folders? Do you have Javascript enabled or disabled in your browser? Which antivirus are you using? Which firewall program are you using, and what firewall exceptions are needed in that firewall for the software you require for your work to run? What anti-spyware program are you using, and are you *sure* you don't have spyware installed on your Windows system?
If you're using Windows at work at even small companies, you're using AD, where all these configuration decisions are made by the network administrator team and your desktop is pretty much locked down, with the exact validated set of software and OS patches needed to run, and you don't have administrative access to fubar the system. The usual exception is if you're a developer, where you need to regularly blow things away to test your software. Even there, you're better off using VMware or KVM rather than doing it on actual physical hardware.
BTW, Linux isn't much better here, other than that it usually comes pre-configured with defaults that work for most folks for everything except backups. I have glumly come to the conclusion that if I want something equivalent to or better than MacOS's Time Machine on Linux for doing time-based incremental backups, I'm going to have to write it myself, and it's going to have to rely on LVM's snapshotting mechanism to do a consistent backup until BTRFS is ready. Yay team. At least we have SQLite nowadays, not like when I designed BRU Server back in the late 90's...
That said, ChromeOS isn't useful for me. It might be useful for my mother, though. All she does is read email and browse the Internet. The only reason her machine, an HP laptop, isn't a reeking virus-infested spyware-riddled useless pile of plastic is because my brother does all the administrative stuff for her. Otherwise it'd be useless.
All the latest video cameras are either POE or WiFi. We currently have around 50 WiFi cameras in our facility and roughly 200 POE cameras (we do camera validation with VDMR venders). Composite-over-coax cameras are not used for any installation that has more than four cameras nowadays because it doesn't scale -- modern-day legal requirements pretty much require you to store video data for *all* the cameras for a specified amount of time, you can't do like the old days where you just flipped between cameras recording snippets to a VCR tape. Try doing that in today's legal environment and someone gets raped while your cameras aren't recording that area, and you're going to end up with one honkin' big negligence lawsuit against you. Regarding where WiFi cameras are used vs. POE cameras, by and large it depends upon access to power and data. Where wires can be run, POE is preferred for security purposes. If the integrator must instead suck power from, say, the emergency exit light's power source (say we're talking about a fire escape stairwell where it's virtually impossible to run new wires due to the physical firewall requirements), that's where a WiFi camera gets plunked on top of the EXIT sign or fire escape light and piggybacks on that power.
Disclaimer: I work for a vendor of video surveillance appliances.
When personal computers came out, IT said "personal computers are toys and useless for real work, we do not allow them in our facility." When the first commercial Linux arrived in late 1995, I heard IT say "Linux is a toy and useless for real work, we do not allow it in our facility." Now I read in this very thread people saying "iPads are toys and useless for real work, we do not allow them." Hint to IT: It didn't work when you said that in 1980, it didn't work when you said that in 1995, and it won't work when you say that today.
I've heard all the excuses over the past 30 years over why IT can't allow the latest technology, and in the end they all ram up against reality. Mordac the Preventer of Information Services may have short-term victories, but in the end the wheels of progress grind him up. Reality simply *IS*. You aren't going to stop the executives from bringing in those things because they outrank you and your rear end will be out on the street if you try to stop them, not to mention that if you don't provide a secure wireless network capable of handling the iPads and other wireless devices that people want to use in your facility, you're going to end up with wildcat devices, often in the hands of untouchables -- people you can't touch, because they outrank you / are mission critical to the company / are close personal friends with the CEO / whatever. I've seen this dynamic -- IT trying to stop new technology from entering the workplace, and being bypassed -- so many times over the years, that you'd think IT would get a clue and get ahead of the technology curve rather than trying to downplay the new technology as "just a toy and useless for real work." Yet reading the comments on this article I see IT people doing the same thing that didn't work in 1995, that didn't work in 1980, that won't work today -- trying to keep technology they don't understand / don't like / have no personal use for themselves out of the workplace.
Hint: You might as well start trying to figure out how to make your environment work for ubiquitous wireless devices, because it is *not* a "fad" that's going away. An iPad isn't a substitute for a desktop computer, just as a desktop computer isn't a substitute for a mainframe, but clearly people are finding the things to be useful for *something* if they're wanting it on the work network, and it's not your job as IT to tell them that no, it's *not* useful (when clearly the reality is that it darn well *is* useful for something, even if you don't understand what), it's your job to accept that reality and figure out some way to get the things on your network in a secure and reasonably speedy fashion. Because it will happen regardless -- so you might as well do it right, instead of the futile fight against insecure wildcat access points in the hands of untouchables that will otherwise happen.
I am on a D-STAR discussion list. Apparently the issue is that D-STAR has not previously been an allowed digital mode in France, and there is an old time neanderthal HF ham radio guy in their radio regulatory department (the type of guy who believes ham radio died the moment there was no longer a requirement to build your own HF morse code transceiver in order to get a ham license) who does not believe that *any* digital modes should be allowed who is now in a position to block the adoption of new digital modes. Check out this list of a large number of digital modes that are banned in France (note that this page is in French, but if you are American you should be able to read the huge number of disallowed modes, and the much smaller number of allowed modes at the end). In any event, the whole "can be routed over the Internet" thingy is a base canard being used by this old-school guy to disallow digital modes, rather than the real reason, so ... (shrug).
2) The auto industry is an incredibly capital-intensive industry, it on average takes $2B to create an all-new car from scratch. Tesla doesn't have some of those costs (like the costs of emissions certification and engine design), but has additional new costs (the costs of battery design and electric motor design). Even with the money they just raised, by my counting they're still some $1.5B short of the amount of money needed to mass-produce a competitive design.
3) Manufacturing is *HARD*. Tesla has a lot of design geeks, but very few manufacturing engineers and technicians with automotive industry experience. Manufacturing is where most of these plans fall astray. Tesla now has a gigantic manufacturing facility, thanks to Toyota, but has to fill it with the tooling and processes to mass-produce their car, and that is *not* an easy chore.
In short, add me to the list of those who are dubious. By the time Tesla gets the glitches out and figures out how to manufacture their car, competitors from Nissan and GM will be available for less money. Competing with entrenched incumbents with the same basic product is *never* a recipe for success in today's "free market" environment, which highly favors incumbents in both the financial marketplace and in the supplier marketplace (where most of the suppliers are captive to the incumbents and will supply the incumbents before they supply you, and will supply the incumbents for less money than they'll supply you -- a major problem when critical components in short supply are required by both yourself and the incumbent). I've run into these issues before with manufacturing startups I've worked for, and the solution was either to run for a niche market where the incumbent was not competitive (which usually ended up with the company being bought out by an incumbent if the niche proved profitable) or going out of business (the usual result). If Tesla had started shipping their mass market car two years ago, they would have a chance. Right now, against the Volt and Leaf... uhm.
The wild card: Tesla's battery technology. If Tesla turns into a battery supplier to the auto makers rather than an automaker themselves, they could survive. As an automaker? Color me dubious... this sounds awfully lot like the DeLorean situation, makes you wonder which Tesla founder is going to be discovered shipping crates of cocaine in order to finance parts inventory, hmm.
So you're saying that our politicians were appointed by an evil tyrant, rather than elected by the majority of people in their state or district? Hmm... gosh, I could have *sworn* that I actually *voted* for somebody for President a couple of years ago, and (gasp) the person with the majority of votes WON OFFICE. The fact that Americans consistently vote for the most corrupt politicians, the ones most effective at collecting bribes err campaign contributions... well, what can I say? In a democracy, people get the kind of government they want -- and deserve. Alas.
Or it could be that America gets the government it wants -- and deserves. Whatevah.
So "the government" is an alien and foreign dictatorship imposed on America, rather than a bunch of folks that We The People voted into office to represent the interests of We The People? Gosh, you learn something new every day!
Have to agree, if I were a Fortune 500 company I would use Google mail and apps pretty much about the same time that the Earth froze over. The legal consequences alone are astounding in their repercussions. How do you enforce data retention policies intended to keep documents as long as legally required but not one second longer? Respond to legal discovery? Freeze mailboxes relevant to a specific legal action in order to preserve evidence, while not locking out the user who needs to get his *current* emails? Locate all documents containing references to the words "Acme Inc.", without individually logging onto every user's Google account? Do you understand just how many discovery subpoenas the typical Fortune 500 company receives in the course of a day, and what the repercussions are for not being able to respond to them? Then there's privacy, which will be a huge issue with major healthcare companies and banking institutions who may find that customer privacy laws basically prohibit them from outsourcing any data that may contain any customer-identifiable data (and how would you enforce "no customer-identifiable data" in email, which by definition may be used to communicate with customers?), etc. Frankly, if I were a major company or in a health care field, I'd outsource my email to Google, well, never. That said, it decidedly makes sense for small businesses to use Google Apps rather than Microsoft "We eat your emails!" Exchange. My own employer does so. But we aren't getting sued every day like, say, Google (heh)...
Folks looking for all these classes, sessions, certificates, and training programs are looking for folks who are good at lying on resumes, by and large. Tells you what the work environment is like -- a dog eat dog back-stabbing cesspool of liars and braggarts. Those of us with a long history of what, for a better word, I'll call getting s**t done, avoid such places like the plague, which is why those places whine and complain that they can't find anybody who knows anything who's willing to work for them.
Median salaries across the board shrunk last year. If IT salaries are merely stagnant, that's still better than everybody else in this cruddy economy. I'm happy to be making the exact same thing I made last year. Heck, I'm happy I have a job right now, though I'm not sure how much longer that's going to last. Given what's happening elsewhere in the economy, treading water is a major win. But I guess there just has to be whiners in any profession who will take any excuse to complain...
So what happened if you were a hermit and your neighbors didn't know you and etc.? At that point I was instructed to turn it over to my supervisor, who would then turn in a federal records request that had to go before a special court and resulted in a court order that allowed the Census to pull Social Security records, IRS income tax records, etc. But that never happened during the three months I worked Census, we always got our man, woman, or child :).
So in the end, all you do when you refuse to answer the Census is cost the taxpayers money. A *LOT* of money. I was getting basically $10/hour to go after these "difficult" cases once you added in my mileage charges, and that was in 1995 dollars. If it had to be escalated up to a supervisor and a records request, it cost thousands upon thousands of taxpayer dollars to go through that process. In the end, the government already has all the information that the Census requests... it just costs a lot more money to pull it together from all those vast databases than just asking you on that little form. So you might as well just fill out the friggin' form... it's not as if you're telling the government anything that it doesn't already know, after all. You're just saving taxpayer money, that's pretty much it.
Really? Care to give me a pointer to that Supreme Court decision? The only decisions I'm aware of are regarding use of racial classification as an employment or educational enrollment qualification, and even there, the gathering of racial classification information was not outlawed -- just its use for employment or enrollment decisions. The Supreme Court has repeatedly upheld the Voting Rights Act of 1965 and its requirement that the Census gather racial information in order to apportion districts in order to assure representation for minority populations.