I don't know where you've been hiring or looking for tech jobs in the last couple of years, but outside the Silicon Valley, most UNIX/open-source geeks I know would be thrilled to have a $25k/year job they felt appreciated and useful at. I'm not talking about script kiddies who use Red Hat 'cause they're so 1337, I'm talking about experienced admins who know how to maintain and run large networks, write and update C/Perl/SH/Java code, and are more than willing to keep a pager next to their pillow for midnight emergencies.
I've worked with folks from NASA, Boeing, the NSA, etc., and IMHO, their internal IT departments aren't any more capable than your average medium/large corporation's, they're just more paranoid and conservative about upgrades, connectivity, and innovation. Most of them still run their critical systems on old VAX or IBM mainframes, because they're too paranoid about upgrading to a new, "unproven" system like UNIX or Windows NT. The quality of support they get isn't a product of what they pay their employees, it's the natural outcome of not changing your basic system configuration for 25 years, and keeping the same people on board to support and maintain the identical set of massively-outdated boxes.
You absolutely *can* find experienced, capable admins for less than $35k a year, if you're willing to pay attention to anything besides where they earned their degree, or what overpriced commercial certifications they have -- just look at your average MSCE for an example of how little the corporate "stamp of approval" means in terms of competence. What really matters is whether the people screening and hiring new IT staff have any clue about the technology involved, and whether the company creates a working environment that any self-respecting geek would care to be a part of.
Basically, it can be as simple as installing a couple of pinball/Street Fighter arcade machines, putting an espresso maker in the break room, and not worrying about whether your network guys show up before 10-11am on days when nothing is going wrong. In that kind of working environment, you can take your pick of entirely competent full-time network or system administrators in just about every major urban area in the western world. Of course, if you force everyone to show up at 8:30 wearing a tie and sport coat, and you'll attract only the least self-respecting segment of the geek population, and have plenty of trouble filling high-level positions without offering rediculous compenstation packages.
As much as I (and I suspect much of the/. crowd as well) might like it, Oracle isn't going anywhere, just like Microsoft, BEA, or SAP. In fact, their indorsement of Linux clusters as preferable to Sun "big iron" for running major enterprise databases is a big feather in the cap of the whole open source community, and should be treated as such.
Personally, I think that Linux has an amazing future ahead of it in the server and workstation markets, and that companies like Oracle and IBM that have massive enterprise credibility will help to realize that potential.
Each distro is a different OS in the same way that every installation of Windows 98 or 200 is a different OS -- i.e., the library (DLL) and package (service pack) versions are different from one system to another, and so the behavior of a single dynamically-linked application may vary across them.
However, while Windows application vendors are happy to support every version from 95 to XP, most commercial Linux applications are extremely specific about not only the glibc and kernel (more or less equivalent to the base Windows build) versions they support, they usually tend to refuse to support users under distros other than Red Hat. It's understandable from a revenue-based POV, since Linux as a whole probably consists (even for the most hardcore scientific or engineering app vendors) of less than 10% of their business.
Realistically, though, the effort and cost required to support at least the last few versions of all the major Linux distros (Red Hat, SuSE, Mandrake, Debian, Slackware, etc.) is probably less than the support for Windows 95, 98, ME, NT 4, 2000, and XP. It's not a tecnical issue so much as an economic one, but it does negatively affect the natural competition that exists in the Linux distribution market, since any new vendor has to either work towards 100% compatibility with recent versions of Red Hat, (and therefore use RPM, standard SysV init scripts, etc.) or accept an extremely marginal, source-package-only application support model.
The Debian stable package set is one of the better server installations I've ever worked with -- it has most of the security-awareness of OpenBSD, with the compatibility of a recent Linux distro. However, it is neither designed nor recommended (at least in any circles I've worked in) as a workstation OS, since the versions and patches used include only the most stable and functional pieces of free Linux software available.
Unfortunately, Galeon, Evolution, etc., while quite featureful and more than stable enough for most workstation environments, (i.e., systems where the occasional segafult might mean an hour or two worth of lost work, but not a costly enterprise-wide service loss) are not yet to the point or reliability that serious server environments require. Again, this is not to suggest that they're unsuitable for normal daily use by most people, just that enterprise servers are subject to completely different uptime and consistency requirements than developer or end-user workstations.
In short, Debian stable ranks up there with {Open,Free}BSD and Solaris as one of the best server operating systems available, but it's not a replacement for Gentoo, Mandrake, or Windows 2000/XP as a normal daily-use workstation setup. If you want to run a recent Mozilla or Evolution build on your desktop, work from the Debian 'unstable' repositories, (which are still no less reliable than most distros I've worked with) or try Gentoo, Slackware, or some other power-user system that is designed for the workstation, rather than server, environment.
How about 'a', with the expectation that the user *will* return to your store for future peripheral, documentation, and upgrade purchases? Personally, I would be extremely happy to have a local retail outlet that proved itself at all clueful about Linux/BSD/etc., and sold hardware they knew to be compatible and of reasonably high quality, and would happily go to them pretty much exclusively for future purchases.
I'm even one of those exception types who tend to buy a retail-boxed copy of at least one free OS distribution every six months or so, if for not other reason than to have nice pre-packaged CDs to hand off to friends and family when I'm evangelizing to them. Right now, Fry's is the only place I can even think of in the Portland, OR area to "buy" a copy of a recent Linux distro.
Speaking for myself, a college-educated programmer with about four years of experience, (including Java, C++, Common Lisp, CORBA, XML-RPC, webapps, etc., etc.) I would happily take a job at one of the crappier electronics stores right about now, considering the job market up here in beautiful Stumptown (aka Portland) Oregon. The unemployment rate around here is officially around 8%, which means something like 150,000-200,000 people are looking for work in a metro area of less than two million.
Of course, I could move, but it's easier said than done when you're broke and have a basement full of worthless old electronics...
I had an even more impressive experience at the Fry's up here in Portland, OR (which is not one of the more impressive ones, but very little else exists in the area to compete with it) -- an Fry's employee not only knew where I could find a number of items outside of his department, but was able to tell me flat out that they wouldn't have a fairly-priced sound card with digital optical I/O ports, and that I should go to one of the online music gear retailers instead.
Imagine that: a customer service person who actually gives you good enough service to honestly tell you what you should but elsewhere! I'm not sure if the guy just didn't care one way or the other, which would be entirely reasonable, from what I hear and have seen of how Fry's treats their employees, or whether he was actually good enough at his job to recognize a semi-intelligent question, and know that I would come back to a place that dealt with me that fairly.
Of course, I haven't been able to find that guy again in a couple of return trips, so he probably got sacked for similar honesty with a manager within earshot or something.
You should read the above article about the exit checks -- they still cost an extra 10% or so, since the people doing the checking get a 10% comission on any unpaid items they can ID in people's carts.
Capitalism doesn't make things cheaper than anarchy, it just barrages you with marketing until you thing that you're getting a better deal.
Nice sentiment, but painfully naive -- there is no such thing as an 'opt-out' anymore. Every bit of personal information that private or public interests can gather on you is fair game, and the market for such information will probably only grow as interactive media increasingly replace broadcast channels over the next few decades.
Personally, I wouldn't mind it so much if the reverse was also true, and those interests scanning your personal history for commercial or criminal trends were also subject to the same level of transparency.
Personally, I think that getting rid of credit cards, or at least the whole credit rating system that dominates so much of Western business, wouldn't be that bad of an idea. While Americans are better off in terms of income than just about every other country out there, they also have rediculous debt loads -- i.e., on the order of 1.5 to 2 times their yearly income.
Personally, I'm amazed by the number of people who constantly complain about taxes, lack of promotion/raises at work, or any other excuse to explain their financial problems, and yet are actually proud of the fact that they pay out 10-20% interest rates on thousands or tens of thousands of dollars in credit card debt.
Acxiom *is* responsible for what happens to the personal data they're entrusted with -- whether or not there are legal ramifications, this should affect their credibility (no pun intended) with clients. My only fear is that the current Federal administration will use this as an excuse to institute further "anti-terrorism" measures to combat "hackers", meaning anyone with the means and desire to research and experiment with security, crypto, and networking.
Re:Former perl, python, java geek gone to Ruby
on
Ruby 1.8.0 Released
·
· Score: 1
Code blocks are actually just convenient syntactic sugar for anonymous functions for common uses like iteration, filtering, and callbacks. You still have the option of preceeding the block with a 'proc' or 'lambda' call, to turn it into a full-fledged, 'callable' code object, or of using the 'obj.method(:name)' to explicitly capture (instead of call) an object method, and then pass it around, store it, etc.
I'm surprised no one's mentioned the most significant difference (IMHO, anyway) between Ruby and Perl/Python/Tcl/Lua/etc.: first-class continuations. While most people will probably never touch them, the fact that they're there means that you can add your own call/return or exception-handling operators to the language.
Sure, you don't have macros, like in Lisp/Scheme environments, but you do have extremely flexible string handling, the ability to execure eval in the instance, class, or module level of any term you can name, and the convenience of method invocation being *the* standard syntax in the language, so that something like 'typed_attr:name => String' looks quite natural, and can evaluate to an arbitrary code insertion or update.
Really, the core semantics of Ruby are basically Smalltalk, with richer meta-object features and a much more POSIX-like standard library, but without the persistent heap and standard MVC GUI library. Mix in a bit of Scheme for keywords like 'call_cc' and 'lambda', and then stir in a bit of Perl for regexp and flexible 'if' and 'unless' placement, and you've got a very unique and flexible language.
You're basically describing the article-moderation system on K5, which allows site members to choose which articles make it to the homepage, and also divides comments into 'editorial' and 'topical'. It's also based on Apache/mod_perl/MySQL, and available at the scoop source website.
DocBook is fine for technical documentation, which it was designed for, but doesn't really have the flexibility that TeX/LaTeX do -- and at least until Conglomerate, or some other graphical XML editor becomes usable on Linux, editing DocBook XML is a painful experience. The sheer complexity of the DocBook DTD makes it almost as hard to work with as most full-blown programming languages.
Check out GNU Stow for one simple implementation of this; also, see the appdir functionality in OS X, where all the resources an application needs (binaries, shared libs, pixmaps, etc.) are bundled into a single directory structure, which is made opaque at the Finder level. For Linux, the ROX Filer project is trying to do something similar, but also has the advantage of backwards-compatibility with traditional (i.e., '/usr/bin', '/usr/local/bin') installation paths.
Personally, I find the directory layout of most Linux systems to be painfully baroque, with the BSDs just a step behind. Both kick the crap out of Windows system layouts, esp. when it comes to quick configuration tweaks and the like, but the simple fact that you have to know how to do shell scripting to install applications for yourself only is rediculout IMHO. I can do it, but it'd be a lot easier for people I'm trying to get started on Linux to never have to worry about entering a password every time they want to install a new version of the Same Game.
I haven't done much tinkering with FreeBSD on laptops, (esp. since all the FreeBSD laptop compatibility documentation I've been able to find is at least two years old -- tsk, tsk, boys!) but I've had decent success with OpenBSD, and NetBSD has floored me by working perfectly on just about every piece of hardware I've thrown at it.
Let me give you an example: about a year ago, I was broke, but wanted a cheap laptop with 802.11b for lightweight scripting and admin work for my web development clients. I spent a couple of days poking around eBay, until I found an IBM Thinkpad 560 (166MHz Pentium, 40MB RAM, 750 MB HD) -- not a beefy machine by any current standards, but at about $200 for laptop, external floppy drive, and PCMCIA wireless card, I was getting quite a bargain.
I started off by installing Debian, which worked fine, except for the fact that current versions of 'apt-get' use about 32 MB of RAM all by themselves! Given that I wanted to run X, (mainly for Dillo, Xchat, and a few other network clients) devoting 80% of my RAM to the package manager alone wasn't really feasible, esp. since with a hard drive that small, I was swapping packages on and off the machine on more or less a daily basis.
So, I decided to try out NetBSD, as I have had excellent luck with OpenBSD on server and firewall boxes in the past, but wanted something a little more hardware-agnostic. After a painless net install off the standard 2 floppy "laptop" disk set (which correctly identified and used my cheapo off-brand wireless card, no less!) I was off and running.
30 minutes of 'pkg_add...' and minor configuration tweaking later, I had a solid *NIX clone running on a 5 year-old laptop, which not only supported the video, sound, and network hardware I had, but even handled such arcana as automatically switching to APM suspend mode when I closed the monitor/lid (which is something I have yet to accomplish with Debian, Red Hat, Gentoo, or Slackware on any laptop I've tried).
Last I heard, Parrot was definitely intended to support continuations, as a low-level primitive for microthreading, generators, and coroutines. At least that's what Dan told me at LL1, and what the Parrot dev list summaries seem to keep indicating. That's not to say that all languages compiling to Parrot will use continuations, of course, but it will be there for those (Scheme, Ruby, and perhaps some day Smalltalk?) that do.
Parrot is indeed designed to be a more dynamic runtime environment than Java, C#, etc., but that's really more of a compiler-level issue than a VM one -- i.e., compile-time type checking isn't something you implement at the VM level. And since Parrot supports a number of primitive types within the VM core, you could quite conceivably compile a low-level, C-like language to very efficient Parrot code.
Most environment have one, if not several, options for adding "scripting hooks" to an application -- Apple's AEOSA/AppleScript, Microsoft's Windows Scripting Host, the GIMP's PDB, etc. That one should exist for Java is not really a surprise.
However, it would be nice to see someone develop a portable system of this sort, which could just be used as a common bit of infrastructure on any platform. PDB (procedural database), as used in the GIMP, probably has a good chance of being the most portable, as I think it's only significant dependencies are on glib, which runs on Linux, OS X, and Windows quite nicely.
Actually, since they're asking for a signed bootloader, that would suggest that the X-Box uses cryptographic signatures to verify binaries. The whole point of that is that, while the bootloader binary itself could be copied and distributed freely, any modifications would immediately cause rejection, as the new binary wouldn't match its signature. For a modified bootloader, you'd need something like the exploit they're threatening to release, in order to circumvent the normal security checks.
This is a Windows problem only as long as Windows rules to corporate and desktop market; if there were, say, 30% market share of Linux machines out there to worry about, there would be much closer to 30% of a share of virii, worms, backdoors, etc. for that market. So long as Linux, FreeBSD, et. al. are fairly unusual systems to find inside the firewall, they will be (somewhat) less commonly-targeted systems for network attacks.
It's an unpleasant side-effect of the "security does not come through obscurity" argument: since truly strong security is more or less impossible for fully-networked commodity workstations, the more popular an operating system or protocol server implementation is, the more likely it is to be hacked, cracked, and just generally abused.
I've seen this even within the microcosm of Linux servers; the one time I tried to put a relatively well-firewalled (but not, unfortunately, religiously-patched) Red Hat server out on the net, it was hit with a rootkit within a week. Once that was replaced with an OpenBSD system ru awanning the same services, (albiet with a somewhat more recent version of OpenSSH) I was free to check back no more than once every few days to make sure that everything was in order.
(Note: before anyone flames me for my sloppy sysadmin practices, please be aware of two facts: one, at the time, I was already working 40+ hours a week as a lowly coder, and was solely responsible for the design, development, deployment, and maintenance of the dynamic product support website whose server got cracked, and two, I've more than learned my lesson, and now know how to firewall, audit, and harden a system well enough to be back to the point of worrying about application, rather than network or OS-level, security. And, I no longer put anything running Red Hat anywhere near an open port and public IP address, unless I'm ready to wipe and reinstall at a moment's notice.)
Last summer, I accepted a contract with a client to customize and install a Linux POS solution based on L'ane POS, a Perl/Tk/PostgreSQL point-of-sale system designed for touchscreen-equipped terminals. The basic codebase was decent, (if typically under-documented) but since this particular customer had some very weird pricing and product bundle logic requirements, I ended up building them a custom app using Ruby, its Gtk+ bindings, and PostgreSQL.
Needless to say, it was a fair bit of work to buird a full backend and GUI "while they waited," but in the end it was a much better-adapted system for their needs. So I would personally recommend that you keep in mind the possibility that you (or someone else -- I'm available for contract development work, of course;) may need to develop (or at least heavily customize) an open-source solution to really meet your customer's needs. Just like any buy vs. build question, you just need to look at the time pressures, special requirements your customers may have, etc., and come up with some numbers and feature lists for each of the options.
I really shouldn't rise to this bait, but I can't resist: yes, given the choice between those networks, I would choose PBS. Just as I would take a non-profit-driven Internet, public radio over Clear Channel and its ilk, and community mesh wireless networks over 3G mobile phone service.
Google has been, so far at least, a rare exception in the world of privatized communications utilities, by consistently showing a amazing lack of intention to lock people into their service, using either exclusivity agreements of some sort or the simple expedient of proprietary technology (i.e., "increase your PageRank by 10% if you support new encrypted GoogleML tags on your site!"). Nothing is permanent, though, and as we all know, single points of failure are a no-no.
So, to bring all this back somewhere in the general neighborhood of the main story: further distributing the capability to build "mini-Googles", or specialized, community-maintained (but still fairly large-scale in terms of number of pages and links indexed) search tools is very interesting, and a useful body of technology to perpetuate.
Or, even more generally, the technology needed to do large-scale storage, analysis, and manipulation of directed graph structures is a very useful tool. Software analysis often relies heavily on large graphs showing dependencies, caller-callee relationships, variable accesses, etc., as do any number of AI subdomains like knowledge representation and planning systems.
I think the iBook, iMac, and eMac will all stay fairly close to their current specs for a while -- they're all selling fine in their intended channels, and the additional revenue to be made from upping them to 970s (or even G4, in the case of the iBook) really doesn't justify major hardware revisions until the excitement (and initial problems/patches/recalls that will inevitably follow the introduction of a new processor and system architecture) dies down.
Personally, I'd be willing to be that the XServe and desktop lines get the new chip first, with the revised 15" PB still using a (prob. faster) G4 CPU. Until there's some support for processor speed scaling, 64-bit versions of important content production tools (Final Cut Pro, Photoshop, etc.), and a real reason to push the envelope (both in performance and cost), Apple will likely be happy to stay with the formula that has worked so well for the last few years.
People who think that the Apple desktop line has become obsolete have probably never done much high-end uncompressed video, multitrack audio, or other hardware *and* software-intensive work on a Mac. You need PCI slots, support for fast disks (or RAID arrays), physical access to the machine for cable connects, etc., etc., none of which are really viable on a laptop device. Plus, that product line has definitely seen the least attention from Apple over the last couple of years; aside from minor internal tweaks, the G4 desktop you buy now is just a slightly faster version of the one you could get two full years ago.
Most of the heavy-duty apps that Apple will want to demo on the new 64-bit hardware right off the bat, like Oracle, Maya, etc., should already be 64-bit clean, since most of them also run on SPARC, MIPS, and Alpha platforms which have been 64-bit for a long time. Normal consumer apps aren't really going to see much of a performance gain from native 64-bit execution; it's the increased clock speed, cache size, and memory bandwidth that's going to improve things there.
Of course, Apple has already worked hard to support Altivec-optimized versions of common high-performance libraries like BLAS and OpenGL, so I would expect them to spend some time tuning those systems for 64-bit performance. And, of course, the required Photoshop plugins, in the hopes of reclaiming seemingly the only benchmark they really care about from the Wintel platform.
Please, try not to confuse Clinton's desire to serve another term (which, though I haven't heard any reliable sources confirming it, is entirely reasonable and has occurred before in US history) with an attempt at monarchy. If anything, our current president is far more vulnerable to any such accusation, as the Bush "dynasty" and its associated reputation was far more important in his capture of power in this country than any demonstrated record of good leadership or dedication to his country. While Clinton was accused of being a "draft-dodger," George W. Bush actually went AWOL from his National Guard unit. While Clinton was a Rhodes scholar, and a successful lawyer, our commander-in-chief ran an oil company into the ground.
So please, don't level any heavy-handed suggestions of would-be usurping of power against a lawfully-elected, (by a majority of the voters, no less!) experienced ex-president like Clinton. Not that it will matter, of course; even public scorn from his own father can't seem to dent Dubya's ambition or media persona.
I fear for our generation's children, who will know no better than the corporate police state we will pass on to them.
I agree that Bluetooth needs to hit a certain density in common consumer goods before it will be really useful, but some of your examples are pretty unlikely to be part of that process.
Point-by-point:
- A Bluetooth headset would make a terrible home-phone add-on; I expect my cordless phone at home to at least function throughout the main floor of my house, if not into the yard, basement, etc. With a Bluetooth headset, I wouldn't be able to move more than a few paces from the wired phone line.
- Remote control applications could be good, but again, depending on environmental radio noise, etc., I'd probably prefer for my TV to stick with IR. Of course, I don't really watch TV, so I can't speak to how convenient it is to not have to keep track of a seperate remote.
- As for the Bluetooth remote for two boxes, that's (AFAIK) a hypothetical future product which could be accomplished just as easily with a properly implemented IR system. Again, the radio noise and lack of range would also make me think twice about replacing infrared.
- The keyboard and mouse are definitely a useful thing, whether they're connecting to a phone, PDA, or even a desktop PC.
- See above
- Again, device synchronization is one of the most logical (and already well-supported) uses for Bluetooth. If you (or a friend or coworker) have access to a recent-model Mac, you should check out iSync with the built-in Bluetooth adapters. My roommate has a Sony/Ericsson Bluetooth-enabled phone, a Palm Tungsten T, and a new 12" PowerBook, all of which link up and sync nicely via iSync. (Now, if only T-Mobile would get a clue on their GPRS pricing, we could all start chucking out our old 56k modems.)
As for the size and cost of Bluetooth, well...it's really not significantly cheaper or smaller than 802.11b. They both work on similar frequencies, with similar degrees of signal processing complexity. The main differences come from 802.11b being at least an order of magnitude more powerful a signal, and requiring more processing power to take advantage of the bandwidth it offers (which is about *two* orders of magnitude greater).
For extremely low-bandwidth connection of I/O devices and short-range transfer of compact binary data, Bluetooth has some real potential. Much of it's vaunted simplicity and cost savings, though, are simply industry hype, generated largely by the same companies that are trying to sell Bluetooth chipsets and design services to electronics manufacturers, and those manufactorers who are trying to push consumers to upgrade to the new top-of-the-line models that support it.
Slashdot Mirror
I don't know where you've been hiring or looking for tech jobs in the last couple of years, but outside the Silicon Valley, most UNIX/open-source geeks I know would be thrilled to have a $25k/year job they felt appreciated and useful at. I'm not talking about script kiddies who use Red Hat 'cause they're so 1337, I'm talking about experienced admins who know how to maintain and run large networks, write and update C/Perl/SH/Java code, and are more than willing to keep a pager next to their pillow for midnight emergencies.
I've worked with folks from NASA, Boeing, the NSA, etc., and IMHO, their internal IT departments aren't any more capable than your average medium/large corporation's, they're just more paranoid and conservative about upgrades, connectivity, and innovation. Most of them still run their critical systems on old VAX or IBM mainframes, because they're too paranoid about upgrading to a new, "unproven" system like UNIX or Windows NT. The quality of support they get isn't a product of what they pay their employees, it's the natural outcome of not changing your basic system configuration for 25 years, and keeping the same people on board to support and maintain the identical set of massively-outdated boxes.
You absolutely *can* find experienced, capable admins for less than $35k a year, if you're willing to pay attention to anything besides where they earned their degree, or what overpriced commercial certifications they have -- just look at your average MSCE for an example of how little the corporate "stamp of approval" means in terms of competence. What really matters is whether the people screening and hiring new IT staff have any clue about the technology involved, and whether the company creates a working environment that any self-respecting geek would care to be a part of.
Basically, it can be as simple as installing a couple of pinball/Street Fighter arcade machines, putting an espresso maker in the break room, and not worrying about whether your network guys show up before 10-11am on days when nothing is going wrong. In that kind of working environment, you can take your pick of entirely competent full-time network or system administrators in just about every major urban area in the western world. Of course, if you force everyone to show up at 8:30 wearing a tie and sport coat, and you'll attract only the least self-respecting segment of the geek population, and have plenty of trouble filling high-level positions without offering rediculous compenstation packages.
As much as I (and I suspect much of the /. crowd as well) might like it, Oracle isn't going anywhere, just like Microsoft, BEA, or SAP. In fact, their indorsement of Linux clusters as preferable to Sun "big iron" for running major enterprise databases is a big feather in the cap of the whole open source community, and should be treated as such.
Personally, I think that Linux has an amazing future ahead of it in the server and workstation markets, and that companies like Oracle and IBM that have massive enterprise credibility will help to realize that potential.
Each distro is a different OS in the same way that every installation of Windows 98 or 200 is a different OS -- i.e., the library (DLL) and package (service pack) versions are different from one system to another, and so the behavior of a single dynamically-linked application may vary across them.
However, while Windows application vendors are happy to support every version from 95 to XP, most commercial Linux applications are extremely specific about not only the glibc and kernel (more or less equivalent to the base Windows build) versions they support, they usually tend to refuse to support users under distros other than Red Hat. It's understandable from a revenue-based POV, since Linux as a whole probably consists (even for the most hardcore scientific or engineering app vendors) of less than 10% of their business.
Realistically, though, the effort and cost required to support at least the last few versions of all the major Linux distros (Red Hat, SuSE, Mandrake, Debian, Slackware, etc.) is probably less than the support for Windows 95, 98, ME, NT 4, 2000, and XP. It's not a tecnical issue so much as an economic one, but it does negatively affect the natural competition that exists in the Linux distribution market, since any new vendor has to either work towards 100% compatibility with recent versions of Red Hat, (and therefore use RPM, standard SysV init scripts, etc.) or accept an extremely marginal, source-package-only application support model.
The Debian stable package set is one of the better server installations I've ever worked with -- it has most of the security-awareness of OpenBSD, with the compatibility of a recent Linux distro. However, it is neither designed nor recommended (at least in any circles I've worked in) as a workstation OS, since the versions and patches used include only the most stable and functional pieces of free Linux software available.
Unfortunately, Galeon, Evolution, etc., while quite featureful and more than stable enough for most workstation environments, (i.e., systems where the occasional segafult might mean an hour or two worth of lost work, but not a costly enterprise-wide service loss) are not yet to the point or reliability that serious server environments require. Again, this is not to suggest that they're unsuitable for normal daily use by most people, just that enterprise servers are subject to completely different uptime and consistency requirements than developer or end-user workstations.
In short, Debian stable ranks up there with {Open,Free}BSD and Solaris as one of the best server operating systems available, but it's not a replacement for Gentoo, Mandrake, or Windows 2000/XP as a normal daily-use workstation setup. If you want to run a recent Mozilla or Evolution build on your desktop, work from the Debian 'unstable' repositories, (which are still no less reliable than most distros I've worked with) or try Gentoo, Slackware, or some other power-user system that is designed for the workstation, rather than server, environment.
How about 'a', with the expectation that the user *will* return to your store for future peripheral, documentation, and upgrade purchases? Personally, I would be extremely happy to have a local retail outlet that proved itself at all clueful about Linux/BSD/etc., and sold hardware they knew to be compatible and of reasonably high quality, and would happily go to them pretty much exclusively for future purchases.
I'm even one of those exception types who tend to buy a retail-boxed copy of at least one free OS distribution every six months or so, if for not other reason than to have nice pre-packaged CDs to hand off to friends and family when I'm evangelizing to them. Right now, Fry's is the only place I can even think of in the Portland, OR area to "buy" a copy of a recent Linux distro.
Speaking for myself, a college-educated programmer with about four years of experience, (including Java, C++, Common Lisp, CORBA, XML-RPC, webapps, etc., etc.) I would happily take a job at one of the crappier electronics stores right about now, considering the job market up here in beautiful Stumptown (aka Portland) Oregon. The unemployment rate around here is officially around 8%, which means something like 150,000-200,000 people are looking for work in a metro area of less than two million.
Of course, I could move, but it's easier said than done when you're broke and have a basement full of worthless old electronics...
I had an even more impressive experience at the Fry's up here in Portland, OR (which is not one of the more impressive ones, but very little else exists in the area to compete with it) -- an Fry's employee not only knew where I could find a number of items outside of his department, but was able to tell me flat out that they wouldn't have a fairly-priced sound card with digital optical I/O ports, and that I should go to one of the online music gear retailers instead.
Imagine that: a customer service person who actually gives you good enough service to honestly tell you what you should but elsewhere! I'm not sure if the guy just didn't care one way or the other, which would be entirely reasonable, from what I hear and have seen of how Fry's treats their employees, or whether he was actually good enough at his job to recognize a semi-intelligent question, and know that I would come back to a place that dealt with me that fairly.
Of course, I haven't been able to find that guy again in a couple of return trips, so he probably got sacked for similar honesty with a manager within earshot or something.
You should read the above article about the exit checks -- they still cost an extra 10% or so, since the people doing the checking get a 10% comission on any unpaid items they can ID in people's carts.
Capitalism doesn't make things cheaper than anarchy, it just barrages you with marketing until you thing that you're getting a better deal.
Nice sentiment, but painfully naive -- there is no such thing as an 'opt-out' anymore. Every bit of personal information that private or public interests can gather on you is fair game, and the market for such information will probably only grow as interactive media increasingly replace broadcast channels over the next few decades.
Personally, I wouldn't mind it so much if the reverse was also true, and those interests scanning your personal history for commercial or criminal trends were also subject to the same level of transparency.
Personally, I think that getting rid of credit cards, or at least the whole credit rating system that dominates so much of Western business, wouldn't be that bad of an idea. While Americans are better off in terms of income than just about every other country out there, they also have rediculous debt loads -- i.e., on the order of 1.5 to 2 times their yearly income.
Personally, I'm amazed by the number of people who constantly complain about taxes, lack of promotion/raises at work, or any other excuse to explain their financial problems, and yet are actually proud of the fact that they pay out 10-20% interest rates on thousands or tens of thousands of dollars in credit card debt.
Acxiom *is* responsible for what happens to the personal data they're entrusted with -- whether or not there are legal ramifications, this should affect their credibility (no pun intended) with clients. My only fear is that the current Federal administration will use this as an excuse to institute further "anti-terrorism" measures to combat "hackers", meaning anyone with the means and desire to research and experiment with security, crypto, and networking.
Code blocks are actually just convenient syntactic sugar for anonymous functions for common uses like iteration, filtering, and callbacks. You still have the option of preceeding the block with a 'proc' or 'lambda' call, to turn it into a full-fledged, 'callable' code object, or of using the 'obj.method(:name)' to explicitly capture (instead of call) an object method, and then pass it around, store it, etc.
:name => String' looks quite natural, and can evaluate to an arbitrary code insertion or update.
I'm surprised no one's mentioned the most significant difference (IMHO, anyway) between Ruby and Perl/Python/Tcl/Lua/etc.: first-class continuations. While most people will probably never touch them, the fact that they're there means that you can add your own call/return or exception-handling operators to the language.
Sure, you don't have macros, like in Lisp/Scheme environments, but you do have extremely flexible string handling, the ability to execure eval in the instance, class, or module level of any term you can name, and the convenience of method invocation being *the* standard syntax in the language, so that something like 'typed_attr
Really, the core semantics of Ruby are basically Smalltalk, with richer meta-object features and a much more POSIX-like standard library, but without the persistent heap and standard MVC GUI library. Mix in a bit of Scheme for keywords like 'call_cc' and 'lambda', and then stir in a bit of Perl for regexp and flexible 'if' and 'unless' placement, and you've got a very unique and flexible language.
You're basically describing the article-moderation system on K5, which allows site members to choose which articles make it to the homepage, and also divides comments into 'editorial' and 'topical'. It's also based on Apache/mod_perl/MySQL, and available at the scoop source website.
DocBook is fine for technical documentation, which it was designed for, but doesn't really have the flexibility that TeX/LaTeX do -- and at least until Conglomerate, or some other graphical XML editor becomes usable on Linux, editing DocBook XML is a painful experience. The sheer complexity of the DocBook DTD makes it almost as hard to work with as most full-blown programming languages.
Check out GNU Stow for one simple implementation of this; also, see the appdir functionality in OS X, where all the resources an application needs (binaries, shared libs, pixmaps, etc.) are bundled into a single directory structure, which is made opaque at the Finder level. For Linux, the ROX Filer project is trying to do something similar, but also has the advantage of backwards-compatibility with traditional (i.e., '/usr/bin', '/usr/local/bin') installation paths.
Personally, I find the directory layout of most Linux systems to be painfully baroque, with the BSDs just a step behind. Both kick the crap out of Windows system layouts, esp. when it comes to quick configuration tweaks and the like, but the simple fact that you have to know how to do shell scripting to install applications for yourself only is rediculout IMHO. I can do it, but it'd be a lot easier for people I'm trying to get started on Linux to never have to worry about entering a password every time they want to install a new version of the Same Game.
I haven't done much tinkering with FreeBSD on laptops, (esp. since all the FreeBSD laptop compatibility documentation I've been able to find is at least two years old -- tsk, tsk, boys!) but I've had decent success with OpenBSD, and NetBSD has floored me by working perfectly on just about every piece of hardware I've thrown at it.
...' and minor configuration tweaking later, I had a solid *NIX clone running on a 5 year-old laptop, which not only supported the video, sound, and network hardware I had, but even handled such arcana as automatically switching to APM suspend mode when I closed the monitor/lid (which is something I have yet to accomplish with Debian, Red Hat, Gentoo, or Slackware on any laptop I've tried).
Let me give you an example: about a year ago, I was broke, but wanted a cheap laptop with 802.11b for lightweight scripting and admin work for my web development clients. I spent a couple of days poking around eBay, until I found an IBM Thinkpad 560 (166MHz Pentium, 40MB RAM, 750 MB HD) -- not a beefy machine by any current standards, but at about $200 for laptop, external floppy drive, and PCMCIA wireless card, I was getting quite a bargain.
I started off by installing Debian, which worked fine, except for the fact that current versions of 'apt-get' use about 32 MB of RAM all by themselves! Given that I wanted to run X, (mainly for Dillo, Xchat, and a few other network clients) devoting 80% of my RAM to the package manager alone wasn't really feasible, esp. since with a hard drive that small, I was swapping packages on and off the machine on more or less a daily basis.
So, I decided to try out NetBSD, as I have had excellent luck with OpenBSD on server and firewall boxes in the past, but wanted something a little more hardware-agnostic. After a painless net install off the standard 2 floppy "laptop" disk set (which correctly identified and used my cheapo off-brand wireless card, no less!) I was off and running.
30 minutes of 'pkg_add
Last I heard, Parrot was definitely intended to support continuations, as a low-level primitive for microthreading, generators, and coroutines. At least that's what Dan told me at LL1, and what the Parrot dev list summaries seem to keep indicating. That's not to say that all languages compiling to Parrot will use continuations, of course, but it will be there for those (Scheme, Ruby, and perhaps some day Smalltalk?) that do.
Parrot is indeed designed to be a more dynamic runtime environment than Java, C#, etc., but that's really more of a compiler-level issue than a VM one -- i.e., compile-time type checking isn't something you implement at the VM level. And since Parrot supports a number of primitive types within the VM core, you could quite conceivably compile a low-level, C-like language to very efficient Parrot code.
Most environment have one, if not several, options for adding "scripting hooks" to an application -- Apple's AEOSA/AppleScript, Microsoft's Windows Scripting Host, the GIMP's PDB, etc. That one should exist for Java is not really a surprise.
However, it would be nice to see someone develop a portable system of this sort, which could just be used as a common bit of infrastructure on any platform. PDB (procedural database), as used in the GIMP, probably has a good chance of being the most portable, as I think it's only significant dependencies are on glib, which runs on Linux, OS X, and Windows quite nicely.
Actually, since they're asking for a signed bootloader, that would suggest that the X-Box uses cryptographic signatures to verify binaries. The whole point of that is that, while the bootloader binary itself could be copied and distributed freely, any modifications would immediately cause rejection, as the new binary wouldn't match its signature. For a modified bootloader, you'd need something like the exploit they're threatening to release, in order to circumvent the normal security checks.
This is a Windows problem only as long as Windows rules to corporate and desktop market; if there were, say, 30% market share of Linux machines out there to worry about, there would be much closer to 30% of a share of virii, worms, backdoors, etc. for that market. So long as Linux, FreeBSD, et. al. are fairly unusual systems to find inside the firewall, they will be (somewhat) less commonly-targeted systems for network attacks.
It's an unpleasant side-effect of the "security does not come through obscurity" argument: since truly strong security is more or less impossible for fully-networked commodity workstations, the more popular an operating system or protocol server implementation is, the more likely it is to be hacked, cracked, and just generally abused.
I've seen this even within the microcosm of Linux servers; the one time I tried to put a relatively well-firewalled (but not, unfortunately, religiously-patched) Red Hat server out on the net, it was hit with a rootkit within a week. Once that was replaced with an OpenBSD system ru awanning the same services, (albiet with a somewhat more recent version of OpenSSH) I was free to check back no more than once every few days to make sure that everything was in order.
(Note: before anyone flames me for my sloppy sysadmin practices, please be aware of two facts: one, at the time, I was already working 40+ hours a week as a lowly coder, and was solely responsible for the design, development, deployment, and maintenance of the dynamic product support website whose server got cracked, and two, I've more than learned my lesson, and now know how to firewall, audit, and harden a system well enough to be back to the point of worrying about application, rather than network or OS-level, security. And, I no longer put anything running Red Hat anywhere near an open port and public IP address, unless I'm ready to wipe and reinstall at a moment's notice.)
Last summer, I accepted a contract with a client to customize and install a Linux POS solution based on L'ane POS, a Perl/Tk/PostgreSQL point-of-sale system designed for touchscreen-equipped terminals. The basic codebase was decent, (if typically under-documented) but since this particular customer had some very weird pricing and product bundle logic requirements, I ended up building them a custom app using Ruby, its Gtk+ bindings, and PostgreSQL.
;) may need to develop (or at least heavily customize) an open-source solution to really meet your customer's needs. Just like any buy vs. build question, you just need to look at the time pressures, special requirements your customers may have, etc., and come up with some numbers and feature lists for each of the options.
Needless to say, it was a fair bit of work to buird a full backend and GUI "while they waited," but in the end it was a much better-adapted system for their needs. So I would personally recommend that you keep in mind the possibility that you (or someone else -- I'm available for contract development work, of course
I really shouldn't rise to this bait, but I can't resist: yes, given the choice between those networks, I would choose PBS. Just as I would take a non-profit-driven Internet, public radio over Clear Channel and its ilk, and community mesh wireless networks over 3G mobile phone service.
Google has been, so far at least, a rare exception in the world of privatized communications utilities, by consistently showing a amazing lack of intention to lock people into their service, using either exclusivity agreements of some sort or the simple expedient of proprietary technology (i.e., "increase your PageRank by 10% if you support new encrypted GoogleML tags on your site!"). Nothing is permanent, though, and as we all know, single points of failure are a no-no.
So, to bring all this back somewhere in the general neighborhood of the main story: further distributing the capability to build "mini-Googles", or specialized, community-maintained (but still fairly large-scale in terms of number of pages and links indexed) search tools is very interesting, and a useful body of technology to perpetuate.
Or, even more generally, the technology needed to do large-scale storage, analysis, and manipulation of directed graph structures is a very useful tool. Software analysis often relies heavily on large graphs showing dependencies, caller-callee relationships, variable accesses, etc., as do any number of AI subdomains like knowledge representation and planning systems.
I think the iBook, iMac, and eMac will all stay fairly close to their current specs for a while -- they're all selling fine in their intended channels, and the additional revenue to be made from upping them to 970s (or even G4, in the case of the iBook) really doesn't justify major hardware revisions until the excitement (and initial problems/patches/recalls that will inevitably follow the introduction of a new processor and system architecture) dies down.
Personally, I'd be willing to be that the XServe and desktop lines get the new chip first, with the revised 15" PB still using a (prob. faster) G4 CPU. Until there's some support for processor speed scaling, 64-bit versions of important content production tools (Final Cut Pro, Photoshop, etc.), and a real reason to push the envelope (both in performance and cost), Apple will likely be happy to stay with the formula that has worked so well for the last few years.
People who think that the Apple desktop line has become obsolete have probably never done much high-end uncompressed video, multitrack audio, or other hardware *and* software-intensive work on a Mac. You need PCI slots, support for fast disks (or RAID arrays), physical access to the machine for cable connects, etc., etc., none of which are really viable on a laptop device. Plus, that product line has definitely seen the least attention from Apple over the last couple of years; aside from minor internal tweaks, the G4 desktop you buy now is just a slightly faster version of the one you could get two full years ago.
Most of the heavy-duty apps that Apple will want to demo on the new 64-bit hardware right off the bat, like Oracle, Maya, etc., should already be 64-bit clean, since most of them also run on SPARC, MIPS, and Alpha platforms which have been 64-bit for a long time. Normal consumer apps aren't really going to see much of a performance gain from native 64-bit execution; it's the increased clock speed, cache size, and memory bandwidth that's going to improve things there.
Of course, Apple has already worked hard to support Altivec-optimized versions of common high-performance libraries like BLAS and OpenGL, so I would expect them to spend some time tuning those systems for 64-bit performance. And, of course, the required Photoshop plugins, in the hopes of reclaiming seemingly the only benchmark they really care about from the Wintel platform.
Please, try not to confuse Clinton's desire to serve another term (which, though I haven't heard any reliable sources confirming it, is
entirely reasonable and has occurred before in US history) with an attempt at monarchy. If anything, our current president is far more
vulnerable to any such accusation, as the Bush "dynasty" and its associated reputation was far more important in his capture of power in
this country than any demonstrated record of good leadership or dedication to his country. While Clinton was accused of being a
"draft-dodger," George W. Bush actually went AWOL from his National Guard unit. While Clinton was a Rhodes scholar, and a successful
lawyer, our commander-in-chief ran an oil company into the ground.
So please, don't level any heavy-handed suggestions of would-be usurping of power against a lawfully-elected, (by a majority of the
voters, no less!) experienced ex-president like Clinton. Not that it will matter, of course; even public scorn from his own father can't
seem to dent Dubya's ambition or media persona.
I fear for our generation's children, who will know no better than the corporate police state we will pass on to them.
I agree that Bluetooth needs to hit a certain density in common consumer goods before it will be really useful, but some of your examples are pretty unlikely to be part of that process.
Point-by-point:
- A Bluetooth headset would make a terrible home-phone add-on; I expect my cordless phone at home to at least function throughout the main floor of my house, if not into the yard, basement, etc. With a Bluetooth headset, I wouldn't be able to move more than a few paces from the wired phone line.
- Remote control applications could be good, but again, depending on environmental radio noise, etc., I'd probably prefer for my TV to stick with IR. Of course, I don't really watch TV, so I can't speak to how convenient it is to not have to keep track of a seperate remote.
- As for the Bluetooth remote for two boxes, that's (AFAIK) a hypothetical future product which could be accomplished just as easily with a properly implemented IR system. Again, the radio noise and lack of range would also make me think twice about replacing infrared.
- The keyboard and mouse are definitely a useful thing, whether they're connecting to a phone, PDA, or even a desktop PC.
- See above
- Again, device synchronization is one of the most logical (and already well-supported) uses for Bluetooth. If you (or a friend or coworker) have access to a recent-model Mac, you should check out iSync with the built-in Bluetooth adapters. My roommate has a Sony/Ericsson Bluetooth-enabled phone, a Palm Tungsten T, and a new 12" PowerBook, all of which link up and sync nicely via iSync. (Now, if only T-Mobile would get a clue on their GPRS pricing, we could all start chucking out our old 56k modems.)
As for the size and cost of Bluetooth, well...it's really not significantly cheaper or smaller than 802.11b. They both work on similar frequencies, with similar degrees of signal processing complexity. The main differences come from 802.11b being at least an order of magnitude more powerful a signal, and requiring more processing power to take advantage of the bandwidth it offers (which is about *two* orders of magnitude greater).
For extremely low-bandwidth connection of I/O devices and short-range transfer of compact binary data, Bluetooth has some real potential. Much of it's vaunted simplicity and cost savings, though, are simply industry hype, generated largely by the same companies that are trying to sell Bluetooth chipsets and design services to electronics manufacturers, and those manufactorers who are trying to push consumers to upgrade to the new top-of-the-line models that support it.