What gets me about this is that "Something safe" here means "something safer for me at the expense of safety for others".
Yes, a giant truck is undoubtedly safer for the occupants of the truck. Pity about people in small cars, motorcyclists, cyclists, pedestrians (they're terrible for collision safety with pedestrians) etc if the driver of said giant truck isn't utterly perfectly skilled and attentive.
It makes me really, really angry when I see some soccer mom driving one of those because they're "safer". What about other people's kids?
IIRC MPEG (or at least H.264) uses something vaguely similar to the NTSC space, so yes that'd be more CRT-aligned than LCD-aligned. Truthfully it doesn't matter much - it's the capabilities of the particular device that're key, and the technology only influences those capabilities it doesn't determine them. There are LCDs with much wider gamuts than most CRTs, and CRTs with much wider gamuts than most LCDs.
There are in fact no widely used generic colour spaces that're targeted at LCD displays. sRGB is designed around CRTs, and it shows.
I wouldn't think that this is as simple as reclaiming gamut lost by the move to LCD - not least because there wasn't necessarily any gamut lost in the first place. Moving to cheap, crappy LCD from high-end TV will cost you gamut area, but moving from cheap crappy TV to high-end LCD will most likely gain you gamut space.
In terms of color theory, nothing stops is potentially being real. If you expect to hook this up to some random source and get an improvement, though... good luck. It's not going to happen. With an appropriate 10-bit or 12-bit wide-gamut source, though, it's certainly capable of better results.
The input may be 3-color (RGB), but if it's defined with a wide-gamut space like Adobe RGB, possibly with up to 16 bits of precision per colour channel, then it can represent a huge range of colours. It can do this by defining near-"perfect" primary colours and assuming perfect control over blending of those primaries.
A regular TV, though also an RGB device, has a very different gamut. That's largely because the primary colours the TV uses aren't as bright/saturated or as "perfect" as those in the Adobe RGB space, but it also can't blend its colours as well. Most likely it only uses 8 bits per colour channel, so it has a much more limited range of graduations, further forcing the colour space to be narrowed to avoid banding due to imprecision.
The regular TV must "scale" a wide-gamut input signal in a colour space like Adobe RGB to display it on its own more limited panel. It can do this by "chopping off" extreme colours, by scaling the whole lot evenly, or several other methods that're out of scope here. Point is, that they're both RGB devices, but they don't share the same colour space and must convert colours.
So, if the yellow pixel (another primary) expands the gamut of this new TV, then yes, even though it too only takes an RGB signal, it's in theory better, because it can convert a wide-gamut RGB input to its own RGBY space for display with better fidelity than a TV with the same RGB primaries but no Y channel colour achieve.
Another device might still be plain RGB, but for each of the red green and blue primaries it might have much better (closer to "perfectly red" etc) colour. This device might have an overall wider gamut (ie better range of colours) than the RGBY device, though it's likely that the RGBY device's gamut would still be capable of better yellows. (If you're struggling to figure out what I mean, google for "CIE diagram RGB CMYK" to get a feel for it).
Attaining better results through adding a channel and/or having better R,G,B primaries presumes properly colour-managed inputs to gain any benefit, though. In reality, video colour management is in a pathetic and dire state - inputs can be in any number of different colour spaces, there's no real device-to-device negotiation of colour spaces, and it's generally a mess. If you feed a "regular" narrow gamut source through to a TV that's expecting a wide gamut signal, you'll get a vile array of over-saturated over-bright disgusting colour, so this is important. Since this device would rely on wide-gamut RGB input to have any advantage, it'll need a 10-bit or 12-bit HDMI or DisplayPort input with a source that's capable of providing a wider gamut signal (say, BluRay) and is set up to actually do so rather than "scaling" the output video gamut to the expections of most devices.
The fact that most inputs only support 8 bits per channel (and thus aren't very useful for wide-gamut signals because they'll get banding/striping in smooth tones) really doesn't help.
Once you've taken a disk image of the original machine and have the image on a less fragile system, Linux will probably mount it with:
mount -t sysv -o loop/path/to/image/mnt/tmp
(possibly with any required -o offset= if it's a full-disk image not just an image of the partition/slice containing the file system).
Failing that, you can probably read it with SCO OpenServer 5.x if nothing else will handle it. SCO OpenServer still runs under current VMWare releases (though linux-kvm's SCSI HCI implementation is too incomplete so it crashes on kvm) and can be pointed at the disk image that way.
You can still find the old FreeSCO ISOs around on the mouldier corners of the 'net. I can't offer you any, since I only have fully licensed OpenServer 5.0.5 which I can't distribute. It's for a truly amazingly legacy Microsoft Xenix application from 1983!
SCO uses HPFS by default, but I think Xenix used something more elderly. SCO's mount(ADM) lists it only as fs type "XENIX".
True. However, health insurers in the US negotiate separate prices and discounts with providers. The sticker price of a device has little to do with the price a given health insurer pays. It's largely a negotiation ploy by the device manufacturer to push the health insurer's discounted rates up, and to let the insurer claim it gets their customers an "x%" discount on this class of item.
Don't have health insurance? Too bad, they don't really care about you, because you're not where the money is.
Add medical equipment regulatory and compliance costs into the mix, bump the price for a hefty bit of insurance against medical litigation, and you've got yourself one hell of a price tag. The relatively small size of the industry compared to, say, mobile phones doesn't help, nor does the fact that compliance requirements often prevent manufacturers from using off-the-shelf ASICs for common, simple tasks in their devices. A hearing aid DAC or ADC might be much the same as a DAC or ADC for some other purpose, but it's probably custom made for the industry if not the device because of regulatory requirements.
You can also pick up Return to Castle Wolfenstein: Enemy Territory for as a free download. It's an FPS that runs natively on Linux and isn't very demanding of a 3D video card, though it certainly does require a basic one. It's good fun, and while it's old there are lots of people still playing it.
The Ur Quan Masters (was: Star Control 2) at http://sc2.sf.net/ is a masterpiece of a game, runs natively on Linux, and is free.
You can also run a lot of great games under DOSBox. You can get the X-COM series ( UFO Defense, Terror from the Deep, and Apocalypse ) from various online sources for something like $5 US, just make sure they're not DRM-wrapped. I also highly recommend Master of Orion II. All these run great under DOSBox on Linux and require no 3D video capabilties at all. They're all long-running single player strategies, which may not be your kind of thing.
I know - how about I market a new "TotalControl" phone brand that ships without any software, so the buyer can build a whole phone OS from scratch to their taste. Because, really, it's just lazy to expect existing functionality.
That'll be successful in the market, right? (Remember the topic / article?)
My point isn't that I can't write my own non-broken mail client with a new implementation of certificate handling - it's that it's absurd that I should have to replace such basic, core functionality of an existing "smart" phone OS.
In the same way, sure, I can install a file manager app. To do so I have to (a) know they're out there, which an average user may not; (b) evaluate the various offerings, (c) select one and (d) install it. It's a basic feature that really should be there from the start if they're going to call this thing a smartphone - even Symbian S60 has a file manager.
As for self-signed certs - it could be that self-signed certs are actually OK and it's just certs signed by a CA not in the pre-installed CA trust list that're a problem. I only tested a cert signed by a private CA. However, I've seen reports indicating self signed certs are an issue as well as the inability to install new CA certs:
As for doing the work yourself rather than relying on libraries - how much would you enjoy working with C++ without the STL? (OK, bad example, probably a lot - the STL is ghastly). Python without most of the shipping modules? Perl without CPAN? How would you like using a Linux desktop where 2/3 of the apps and libraries didn't exist and you had to hunt down alternative implementations of questionable quality and write what you needed yourself?
Sure, you can do all that. So can I. Do you want to? I don't know about you, but I want to get on with writing useful things, not basic OS and app functionality I want to just use so I can get on with the real work. I especially don't want to find out while trying to use a library to do my real, interesting work that it's been butchered and crippled.
I investigated Android 1.5 when looking at upgrading my phone recently, so I pulled down the SDK and fired up the emulator with an Android 1.5 instance. I was amazed at how limited it is - even more than the iPhone.
SSL/TLS support is painfully, cripplingly limited. You simply *can't* use mail providers that have self-signed certificates or (more likely) have certs signed by a company private CA. Android doesn't support importing CA certificates at all. Android also lacks any support, of any sort, for managing user X.509 certificates (via the common PKCS#12 transport format or otherwise) so if you need to access web or mail services that require you to authenticate with a client certificate, you're out of luck.
Even if your mail provider happens to use a cert signed by one of the pre-installed trusted CAs you'll discover you can't even delete messages or mark them as read using the IMAP client, so you're wasting your time anyway. Guess they want you to give up and use GMail.
The whole thing is built around Google services and things like decent IMAP support are a hopeless afterthought. File manager? Nope, not in any useful sense. Open local HTML documents, PDFs, etc? Not really ( there's a clumsy workaround for the browser that kinda works, but doesn't provide dir indexing so it's pretty useless ). Decent desktop sync? Nope (you're using Google's address book, right? Right?).
Google seems even less interested than Apple does in making it a flexible phone for general use. I'd say part of the reason it's not doing great is because it doesn't do very much, doesn't do it very well, and really has few attractions or distinguishing features over cheaper mid-to-low-end S60-based handsets let alone high-end S60 phones and the iPhone. The SDK and dev tools aren't awful, but can't touch the iPhone, and just don't give you enough platform access, so app development is somewhat more limited. Experienced java devs will spend most of their time swearing at the butchered and cut-down JRE and libraries, and wondering where basic things like platform certificate services are (answer: there aren't any! Too bad!).
Right now, Android seems to be competitive with Nokia's Series 40 and maybe the older Windows Mobile phones, the Sony Ericsson phones, and some of the custom ones like the LG Prada. Pretty but limited, or just limited. It's really just not a smartphone OS yet.
It'd be nice to just run the agent in a VM and isolate your real system that way, but it wouldn't work because they'll almost certainly be filtering by MAC address.
What you _CAN_ do is run the agent on the physical host with a minimal OS install, and then put everything else in a VM. Have the VM connect through the real host using NAT, so it has the same MAC address as the real host. The network won't know the difference.
Remote attestation isn't something that needs to be built into the average PC. On a typical user's desktop, remote attestation doesn't really have any legitimate uses, only evil ones.
As a system administrator, I disagree in the strongest possible terms. I'd love to be able to have the domain clients here restricted to an authorized software list. I could let users install things they needed or wanted instead of having to do everything for them, but I could restrict the list of available code to things I'd verified were safe and wouldn't cause system issues, security problems, etc. It'd also offer significant protection against resident malware. It'd be great.
Even being able to detect when a machine had unauthorized software on it would be a huge plus.
The parent poster's point is an excellent one - often the user of the computer isn't the owner, and/or isn't the person responsible for managing and maintaining it. In these cases remote attestation becomes highly attractive.
Competition, I think. In part, at least. We have two major parallel cellular networks (Optus and Telstra), plus one medium sized one (Vodafone) and a small-but-fast-and-high-tech one (Three) that roams to Telstra's network when out of coverage.
3G broadband is getting big here. Hutchison is pushing it *hard* as a major alternative to ADSL/cable, and they're making progress. That means good quality, decent network capacity, and decent pricing.
It used to be horrifying here. Like 1c/kb (yes, kb) for GPRS *or* UMTS service. My mobile plan a mere year and a half ago would've cost $32,000/hour at maximum advertised HSDPA download rate. We've never had the other crap - filtering, blocking, image compression, etc - though, and the prices are plummeting as the carriers fight to pick up users.
Vodafone and Optus push it as a major faclity for smartphones, and also offer 3G modem+plan bundles. Three make mobile internet use a major selling point of their phones, including preinstalling Skype and selling "skype minutes" as part of their mobile plans. Not that you can't just use it or another VoIP service via your normal data allowance anyway. Even Telstra don't block or filter VoIP etc on their network.
The only issue we do really have here is SIM-locking. Most cellular modems and phones are sold SIM-locked to a particular carrier, and tend to carry an unlocking fee if you want it unlocked before your contract runs out. To me, that seems a bit dodgy... just make the minimum spend / contract escape costs high enough so you do OK even if the user has an unused SIM sitting on their desk. Since the carriers *will* generally unlock the phones for a pretty reasonable fee within contract, and usually do it for free post-contract, it's just not that big an issue though.
Oh, and none of my hardware is locked to a carrier or has features disabled. I own it outright and can do what I want with my hardware.
Even my Telstra-branded N95-3 wasn't SIM-locked (though it did take a re-flash to get rid of the vendor branding).
My Dell 5530 HSUPA and Dell 5520 HSDPA mobile broadband Mini-PCI-E cards (rebrands of the Ericsson F307G and some Sierra Wireless card, respectively) aren't SIM-locked and "just work". Under Ubuntu, even (thanks NM 0.7 devs!).
If you've got the kind of issues described in the article summary, your carriers stink.
Mobile Broadband (3G, 4G) services being used to bridge the UK Digital Divide, but is that realistic? The technology has all sorts of problems from slow speeds and high latency to blocking VoIP, MSN Instant Messaging and aggressive image compression... not to mention connection stability."
What?!?
I use a 3G HSDPA service regularly with two different laptops that have built-in HSDPA modems from Sierra Wireless and Ericsson. I also use Nokia and LG phones over Bluetooth tethering (since I'm in Australia and have sensible carriers that don't lock that down).
I get a public IP address. No NAT. No filtering, either. Full use of VoIP (SIP or *ick* Skype), etc. No dodgy proxy hacks with image compression or other nasties. It's just a regularly IP service.
It's fast. Not ADSL2+-over-wifi fast, but quite fast enough for everything I need to do, including VNC/RDP remote control of machines at work, SSH, etc. Latency is occasionally a wee bit high, but nothing too bad.
It's pretty stable - it only goes a bit flakey when going through (eg) a train tunnel where it completely loses reception. Even then, it often just transparently recovers without apps or the OS ever really noticing. Sitting in one place, it's rock solid.
I use VoIP via my 3G service in my laptop regularly, via both SIP and (when forced, reluctantly) Skype. It's pretty darn solid; the only issues are VERY occasional quality drops due to latency spikes.
With a 1GB per month data allowance (for a wallet-smashing $15 per month... so, about the price of a decent lunch) I can get a lot done. My carrier, Three (Hutchison), is the best priced data carrier in Australia, but Vodafone and Optus aren't too much worse and they have much better coverage, so this is hardly unique.
So... if your 3G service sucks, it's because your carrier sucks, not because the technology does. Unfortunately, it looks like carriers DO suck in the US and the UK, though for different reasons.
In the US, you get hardware you've bought and paid for but is locked down so hard you can barely breathe next to it. Want to install your own apps? Better pay to unlock that feature. Want to use bluetooth/wifi tethering? Better get the "Internet" plan to unlock that feature. Want to use another provider's SIM with *YOUR* hardware, even after your contract has expired? Tough luck.
In the UK, it doesn't seem to be so much locked down as crap. Blocked and filtered up the wazoo, WAP-like transparent proxying and HTML/image reprocessing, private IPs handed out with all traffic through proxies or NAT, etc. Ick.
This will have to change... but it's a carrier problem not a technology one.
Latency is primarily introduced by routing hops (involving store-and-forward routing), not by the links themselves. Furthermore, a low-throughput link can be of lower latency than a much higher throughput link.
ADSL G.DMT, ADSL2, and ADSL2+ circuits, for example, have VERY low latencies. I have 20ms round-trip latencies to my next-hop router in the city centre. That's not bad when you consider that the "next hop" is really quite a few routing hops away through the underlying ATM L2TP circuit over the ISP's backhaul.
Latencies to the ISP's border router are about 21ms.
From there, nothing much will change on a FTTH network. So even if they DRAMATICALLY simplify the backhaul routing and we see a small latency decrease from link technology changes, don't expect more than (say) a 5 or 10 ms latency improvement.
Agreed, the proportion of the population who are positive (as opposed to who test positive) is indeed an important factor in determining whether test accuracy levels are acceptable.
The suitability of a test also depends on the use you're putting the test to, and whether the false negative and false positive rates are the same.
For pre-screening, in order to avoid performing a more expensive test with a very low false positive rate, a false postive rate of 50% would still be fine - but the false negative rate would have to be near-zero (at least as low as the "real" test) lest you turn people with the disease away as uninfected. Even with a 50% false positive rate you're still halving the number of tests you must perform.
On the other hand, say you've developed a test that can detect a form of cancer that's otherwise undetectable, but is treatable if detected early. The drugs required for treatment cause irreparable liver damage, particularly for people who do not have the cancer. In this case, the false positive rate must be extremely low in order to avoid harming people who're healthy and don't need treatment. However, the false negative rate may be almost anything and the test is still useful - if you identify the disease in 40% of afflicted cases tested, it's still worth using on people you suspect might have it.
In another case, if you're testing to determine (say) for a condition that might exclude someone from driving, flying a plane, etc (say a propensity for frequent narcolepsy) then you need an extremely low false negative rate to protect other people, and an extremely low false positive rate to protect the person taking the test from unnecessary exclusion. A test that's inaccurate in either direction probably isn't worth using.
Mac zealots, UNIX/Linux zealots, Windows zealots, and the one lonely Plan 9 zealot really all need to get a life. Deflation of their egos is generally welcomed by everybody other than them - though more often than not attempts just bounce off their mindless rhetoric, circular reasoning, and utter unshakable certainty. The more factually incorrect their beliefs the better.
The Mac people are perhaps the worst. (Note: Many, many years ago when Mac OS 7 was new I used to be one of them - argh!). They can change their story in an instant. "Intel sucks, it's slow, the PowerPC 704e/G3/G4/G5 is the best thing ever" -> "PowerPC is old and crappy, get an Intel CPU, they're great". And that's just one of the more recent examples. Grr. Suuuure, Pascal is the great new language of the future.
Then again, there's nothing quite like hearing a Linux zealot patiently explaining to someone who's having issues with Quicken on their home PC how much better off they'd be if they just install Gentoo or build Linux-from-scatch then install and configure SQL Ledger. The fact that the user in question can't even install the update to Quicken that'd fix the issue by clicking "install update" when automatically prompted doesn't seem to faze them. (This is being written on an Ubuntu box that's also compiling a test SCSI controller bugfix patch in qemu svn, by the way; I'm a Linux user but still loathe the zealots.)
Windows zealots... well, I'm not sure I've met one. Weird, really, given that it's exactly the same sort of mix of great and awful as the other major platforms, albeit with different pluses and minuses.
Props for effort, but I think your comment probably bounced off just as thoroughly as they usually do.
With BSD I have source code. I have a kernel I control. I have a window system that supports network display of applications natively. All my tools work from the command line, instead of having to do things from often-limiting GUIs. Said tools are also documented, which is a nice change from Mac OS X (where the docs for Apple tools are patchy, and rarely in the form of man pages). I can run BSD on any hardware I want instead of a restricted set of marked-up branded equipment. Oh, and did I mention the use of a sensible file system instead of HFS+ ?
The same goes for Linux.
Of course, I also have far fewer device drivers, far FAR fewer apps in many categories, less support for things like graphics tablets, and all sorts of other things than would be the case under Mac OS X (or Windows).
Argh!
Mac OS X has a POSIX subsystem based on a mixture of BSD and GNU tools, and a kernel that is in large part based on BSD's. Calling it BSD is a disservice to both BSD and Mac OS X.
Actually, there's a legal, licensed MP3 decoder available for Linux.
http://www.fluendo.com/resources/fluendo_mp3.php
It's open source (MIT) with binaries approved by Fraunhofer available.
So you're OK even if you do stick strictly to all patent law, live in a country where such law applies to software, and require source to all code running on your system (above BIOS/firmware level).
This depends a lot on the application.
An app that uses (say) a webcam, microphone, and supports sophisticated input devices like pressure-sensitive touchpads will be a lot easier to develop for just one platform. You land up writing your own abstraction layers a lot, and maintaining them is a lot of work.
The better you want to integrate into the OS, the harder things get. Think file manager context menus, global hotkeys, anything like that.
That said, tools like Qt, SDL, OpenAL, etc make a big difference when it comes to writing portable apps that go beyond the basic C/POSIX interfaces. They are improving all the time, too. For example, just last year it was a F**ing nightmare to embed a decent browser in a cross platform app; now it's comparatively trivial especially for Qt applications.
The issue is not that the package formats don't permit dependency specification. The problem is that the package names and version schemes are inconsistent between distros, so it's hard to know what to call the package. As such, you have to make packages of your app for each distro.
That's a pain, but not actually all that bad. As someone who does both win32 and Linux development, I'd say they're both about equally excruciating.
Yes, it could be useful for examining the output of the query in non-performance terms. For complex queries I can easily see how that could be useful.
That may, in fact, be the whole idea behind the tool - to help reduce or eliminate execution of grossly incorrect queries that don't do what the user wants.
Tools like EXPLAIN aren't as useful for that, either, as the query looks quite different after the query optimiser is done with it. Additionally EXPLAIN output usually drops detail about specific fields, so it's not really possible to predict the results of the query from explain output alone. That said, it's quite possible to spot issues like a join without a filter.
The term SELECT statement generally refers to the whole statement, including FROM, WHERE, HAVING, etc clauses.
This is pretty clear in context, as it'd be nonsensical to produce a graphical explain tool for the result field list in the SELECT clause its self.
That's why the parent said SELECT statement not SELECT clause.
As it happens the same issues regarding the need for planner knowledge etc are true for DML like INSERT, UPDATE and DELETE. It's not about SELECT at all, but rather any non-DDL query.
Slashdot Mirror
What gets me about this is that "Something safe" here means "something safer for me at the expense of safety for others".
Yes, a giant truck is undoubtedly safer for the occupants of the truck. Pity about people in small cars, motorcyclists, cyclists, pedestrians (they're terrible for collision safety with pedestrians) etc if the driver of said giant truck isn't utterly perfectly skilled and attentive.
It makes me really, really angry when I see some soccer mom driving one of those because they're "safer". What about other people's kids?
IIRC MPEG (or at least H.264) uses something vaguely similar to the NTSC space, so yes that'd be more CRT-aligned than LCD-aligned. Truthfully it doesn't matter much - it's the capabilities of the particular device that're key, and the technology only influences those capabilities it doesn't determine them. There are LCDs with much wider gamuts than most CRTs, and CRTs with much wider gamuts than most LCDs.
There are in fact no widely used generic colour spaces that're targeted at LCD displays. sRGB is designed around CRTs, and it shows.
I wouldn't think that this is as simple as reclaiming gamut lost by the move to LCD - not least because there wasn't necessarily any gamut lost in the first place. Moving to cheap, crappy LCD from high-end TV will cost you gamut area, but moving from cheap crappy TV to high-end LCD will most likely gain you gamut space.
In terms of color theory, nothing stops is potentially being real. If you expect to hook this up to some random source and get an improvement, though ... good luck. It's not going to happen. With an appropriate 10-bit or 12-bit wide-gamut source, though, it's certainly capable of better results.
The input may be 3-color (RGB), but if it's defined with a wide-gamut space like Adobe RGB, possibly with up to 16 bits of precision per colour channel, then it can represent a huge range of colours. It can do this by defining near-"perfect" primary colours and assuming perfect control over blending of those primaries.
A regular TV, though also an RGB device, has a very different gamut. That's largely because the primary colours the TV uses aren't as bright/saturated or as "perfect" as those in the Adobe RGB space, but it also can't blend its colours as well. Most likely it only uses 8 bits per colour channel, so it has a much more limited range of graduations, further forcing the colour space to be narrowed to avoid banding due to imprecision.
The regular TV must "scale" a wide-gamut input signal in a colour space like Adobe RGB to display it on its own more limited panel. It can do this by "chopping off" extreme colours, by scaling the whole lot evenly, or several other methods that're out of scope here. Point is, that they're both RGB devices, but they don't share the same colour space and must convert colours.
So, if the yellow pixel (another primary) expands the gamut of this new TV, then yes, even though it too only takes an RGB signal, it's in theory better, because it can convert a wide-gamut RGB input to its own RGBY space for display with better fidelity than a TV with the same RGB primaries but no Y channel colour achieve.
Another device might still be plain RGB, but for each of the red green and blue primaries it might have much better (closer to "perfectly red" etc) colour. This device might have an overall wider gamut (ie better range of colours) than the RGBY device, though it's likely that the RGBY device's gamut would still be capable of better yellows. (If you're struggling to figure out what I mean, google for "CIE diagram RGB CMYK" to get a feel for it).
Attaining better results through adding a channel and/or having better R,G,B primaries presumes properly colour-managed inputs to gain any benefit, though. In reality, video colour management is in a pathetic and dire state - inputs can be in any number of different colour spaces, there's no real device-to-device negotiation of colour spaces, and it's generally a mess. If you feed a "regular" narrow gamut source through to a TV that's expecting a wide gamut signal, you'll get a vile array of over-saturated over-bright disgusting colour, so this is important. Since this device would rely on wide-gamut RGB input to have any advantage, it'll need a 10-bit or 12-bit HDMI or DisplayPort input with a source that's capable of providing a wider gamut signal (say, BluRay) and is set up to actually do so rather than "scaling" the output video gamut to the expections of most devices.
The fact that most inputs only support 8 bits per channel (and thus aren't very useful for wide-gamut signals because they'll get banding/striping in smooth tones) really doesn't help.
Once you've taken a disk image of the original machine and have the image on a less fragile system, Linux will probably mount it with:
mount -t sysv -o loop /path/to/image /mnt/tmp
(possibly with any required -o offset= if it's a full-disk image not just an image of the partition/slice containing the file system).
Failing that, you can probably read it with SCO OpenServer 5.x if nothing else will handle it. SCO OpenServer still runs under current VMWare releases (though linux-kvm's SCSI HCI implementation is too incomplete so it crashes on kvm) and can be pointed at the disk image that way.
You can still find the old FreeSCO ISOs around on the mouldier corners of the 'net. I can't offer you any, since I only have fully licensed OpenServer 5.0.5 which I can't distribute. It's for a truly amazingly legacy Microsoft Xenix application from 1983!
SCO uses HPFS by default, but I think Xenix used something more elderly. SCO's mount(ADM) lists it only as fs type "XENIX".
True. However, health insurers in the US negotiate separate prices and discounts with providers. The sticker price of a device has little to do with the price a given health insurer pays. It's largely a negotiation ploy by the device manufacturer to push the health insurer's discounted rates up, and to let the insurer claim it gets their customers an "x%" discount on this class of item.
Don't have health insurance? Too bad, they don't really care about you, because you're not where the money is.
Add medical equipment regulatory and compliance costs into the mix, bump the price for a hefty bit of insurance against medical litigation, and you've got yourself one hell of a price tag. The relatively small size of the industry compared to, say, mobile phones doesn't help, nor does the fact that compliance requirements often prevent manufacturers from using off-the-shelf ASICs for common, simple tasks in their devices. A hearing aid DAC or ADC might be much the same as a DAC or ADC for some other purpose, but it's probably custom made for the industry if not the device because of regulatory requirements.
All that drives prices through the roof.
http://google.com/search?q=%22X-Com%22%20+buy%20-steam
You can also pick up Return to Castle Wolfenstein: Enemy Territory for as a free download. It's an FPS that runs natively on Linux and isn't very demanding of a 3D video card, though it certainly does require a basic one. It's good fun, and while it's old there are lots of people still playing it.
The Ur Quan Masters (was: Star Control 2) at http://sc2.sf.net/ is a masterpiece of a game, runs natively on Linux, and is free.
You can also run a lot of great games under DOSBox. You can get the X-COM series ( UFO Defense, Terror from the Deep, and Apocalypse ) from various online sources for something like $5 US, just make sure they're not DRM-wrapped. I also highly recommend Master of Orion II. All these run great under DOSBox on Linux and require no 3D video capabilties at all. They're all long-running single player strategies, which may not be your kind of thing.
I know - how about I market a new "TotalControl" phone brand that ships without any software, so the buyer can build a whole phone OS from scratch to their taste. Because, really, it's just lazy to expect existing functionality.
That'll be successful in the market, right? (Remember the topic / article?)
My point isn't that I can't write my own non-broken mail client with a new implementation of certificate handling - it's that it's absurd that I should have to replace such basic, core functionality of an existing "smart" phone OS.
In the same way, sure, I can install a file manager app. To do so I have to (a) know they're out there, which an average user may not; (b) evaluate the various offerings, (c) select one and (d) install it. It's a basic feature that really should be there from the start if they're going to call this thing a smartphone - even Symbian S60 has a file manager.
As for self-signed certs - it could be that self-signed certs are actually OK and it's just certs signed by a CA not in the pre-installed CA trust list that're a problem. I only tested a cert signed by a private CA. However, I've seen reports indicating self signed certs are an issue as well as the inability to install new CA certs:
As for doing the work yourself rather than relying on libraries - how much would you enjoy working with C++ without the STL? (OK, bad example, probably a lot - the STL is ghastly). Python without most of the shipping modules? Perl without CPAN? How would you like using a Linux desktop where 2/3 of the apps and libraries didn't exist and you had to hunt down alternative implementations of questionable quality and write what you needed yourself?
Sure, you can do all that. So can I. Do you want to? I don't know about you, but I want to get on with writing useful things, not basic OS and app functionality I want to just use so I can get on with the real work. I especially don't want to find out while trying to use a library to do my real, interesting work that it's been butchered and crippled.
I investigated Android 1.5 when looking at upgrading my phone recently, so I pulled down the SDK and fired up the emulator with an Android 1.5 instance. I was amazed at how limited it is - even more than the iPhone.
SSL/TLS support is painfully, cripplingly limited. You simply *can't* use mail providers that have self-signed certificates or (more likely) have certs signed by a company private CA. Android doesn't support importing CA certificates at all. Android also lacks any support, of any sort, for managing user X.509 certificates (via the common PKCS#12 transport format or otherwise) so if you need to access web or mail services that require you to authenticate with a client certificate, you're out of luck.
Even if your mail provider happens to use a cert signed by one of the pre-installed trusted CAs you'll discover you can't even delete messages or mark them as read using the IMAP client, so you're wasting your time anyway. Guess they want you to give up and use GMail.
The whole thing is built around Google services and things like decent IMAP support are a hopeless afterthought. File manager? Nope, not in any useful sense. Open local HTML documents, PDFs, etc? Not really ( there's a clumsy workaround for the browser that kinda works, but doesn't provide dir indexing so it's pretty useless ). Decent desktop sync? Nope (you're using Google's address book, right? Right?).
Google seems even less interested than Apple does in making it a flexible phone for general use. I'd say part of the reason it's not doing great is because it doesn't do very much, doesn't do it very well, and really has few attractions or distinguishing features over cheaper mid-to-low-end S60-based handsets let alone high-end S60 phones and the iPhone. The SDK and dev tools aren't awful, but can't touch the iPhone, and just don't give you enough platform access, so app development is somewhat more limited. Experienced java devs will spend most of their time swearing at the butchered and cut-down JRE and libraries, and wondering where basic things like platform certificate services are (answer: there aren't any! Too bad!).
Right now, Android seems to be competitive with Nokia's Series 40 and maybe the older Windows Mobile phones, the Sony Ericsson phones, and some of the custom ones like the LG Prada. Pretty but limited, or just limited. It's really just not a smartphone OS yet.
It'd be nice to just run the agent in a VM and isolate your real system that way, but it wouldn't work because they'll almost certainly be filtering by MAC address.
What you _CAN_ do is run the agent on the physical host with a minimal OS install, and then put everything else in a VM. Have the VM connect through the real host using NAT, so it has the same MAC address as the real host. The network won't know the difference.
As a system administrator, I disagree in the strongest possible terms. I'd love to be able to have the domain clients here restricted to an authorized software list. I could let users install things they needed or wanted instead of having to do everything for them, but I could restrict the list of available code to things I'd verified were safe and wouldn't cause system issues, security problems, etc. It'd also offer significant protection against resident malware. It'd be great.
Even being able to detect when a machine had unauthorized software on it would be a huge plus.
The parent poster's point is an excellent one - often the user of the computer isn't the owner, and/or isn't the person responsible for managing and maintaining it. In these cases remote attestation becomes highly attractive.
Competition, I think. In part, at least. We have two major parallel cellular networks (Optus and Telstra), plus one medium sized one (Vodafone) and a small-but-fast-and-high-tech one (Three) that roams to Telstra's network when out of coverage.
3G broadband is getting big here. Hutchison is pushing it *hard* as a major alternative to ADSL/cable, and they're making progress. That means good quality, decent network capacity, and decent pricing.
It used to be horrifying here. Like 1c/kb (yes, kb) for GPRS *or* UMTS service. My mobile plan a mere year and a half ago would've cost $32,000/hour at maximum advertised HSDPA download rate. We've never had the other crap - filtering, blocking, image compression, etc - though, and the prices are plummeting as the carriers fight to pick up users.
Vodafone and Optus push it as a major faclity for smartphones, and also offer 3G modem+plan bundles. Three make mobile internet use a major selling point of their phones, including preinstalling Skype and selling "skype minutes" as part of their mobile plans. Not that you can't just use it or another VoIP service via your normal data allowance anyway. Even Telstra don't block or filter VoIP etc on their network.
The only issue we do really have here is SIM-locking. Most cellular modems and phones are sold SIM-locked to a particular carrier, and tend to carry an unlocking fee if you want it unlocked before your contract runs out. To me, that seems a bit dodgy ... just make the minimum spend / contract escape costs high enough so you do OK even if the user has an unused SIM sitting on their desk. Since the carriers *will* generally unlock the phones for a pretty reasonable fee within contract, and usually do it for free post-contract, it's just not that big an issue though.
Oh, and none of my hardware is locked to a carrier or has features disabled. I own it outright and can do what I want with my hardware.
Even my Telstra-branded N95-3 wasn't SIM-locked (though it did take a re-flash to get rid of the vendor branding).
My Dell 5530 HSUPA and Dell 5520 HSDPA mobile broadband Mini-PCI-E cards (rebrands of the Ericsson F307G and some Sierra Wireless card, respectively) aren't SIM-locked and "just work". Under Ubuntu, even (thanks NM 0.7 devs!).
If you've got the kind of issues described in the article summary, your carriers stink.
What?!?
I use a 3G HSDPA service regularly with two different laptops that have built-in HSDPA modems from Sierra Wireless and Ericsson. I also use Nokia and LG phones over Bluetooth tethering (since I'm in Australia and have sensible carriers that don't lock that down).
I get a public IP address. No NAT. No filtering, either. Full use of VoIP (SIP or *ick* Skype), etc. No dodgy proxy hacks with image compression or other nasties. It's just a regularly IP service.
It's fast. Not ADSL2+-over-wifi fast, but quite fast enough for everything I need to do, including VNC/RDP remote control of machines at work, SSH, etc. Latency is occasionally a wee bit high, but nothing too bad.
It's pretty stable - it only goes a bit flakey when going through (eg) a train tunnel where it completely loses reception. Even then, it often just transparently recovers without apps or the OS ever really noticing. Sitting in one place, it's rock solid.
I use VoIP via my 3G service in my laptop regularly, via both SIP and (when forced, reluctantly) Skype. It's pretty darn solid; the only issues are VERY occasional quality drops due to latency spikes.
With a 1GB per month data allowance (for a wallet-smashing $15 per month ... so, about the price of a decent lunch) I can get a lot done. My carrier, Three (Hutchison), is the best priced data carrier in Australia, but Vodafone and Optus aren't too much worse and they have much better coverage, so this is hardly unique.
So ... if your 3G service sucks, it's because your carrier sucks, not because the technology does. Unfortunately, it looks like carriers DO suck in the US and the UK, though for different reasons.
In the US, you get hardware you've bought and paid for but is locked down so hard you can barely breathe next to it. Want to install your own apps? Better pay to unlock that feature. Want to use bluetooth/wifi tethering? Better get the "Internet" plan to unlock that feature. Want to use another provider's SIM with *YOUR* hardware, even after your contract has expired? Tough luck.
In the UK, it doesn't seem to be so much locked down as crap. Blocked and filtered up the wazoo, WAP-like transparent proxying and HTML/image reprocessing, private IPs handed out with all traffic through proxies or NAT, etc. Ick.
This will have to change ... but it's a carrier problem not a technology one.
Why would lag be non-existant?
Latency is primarily introduced by routing hops (involving store-and-forward routing), not by the links themselves. Furthermore, a low-throughput link can be of lower latency than a much higher throughput link.
ADSL G.DMT, ADSL2, and ADSL2+ circuits, for example, have VERY low latencies. I have 20ms round-trip latencies to my next-hop router in the city centre. That's not bad when you consider that the "next hop" is really quite a few routing hops away through the underlying ATM L2TP circuit over the ISP's backhaul.
Latencies to the ISP's border router are about 21ms.
From there, nothing much will change on a FTTH network. So even if they DRAMATICALLY simplify the backhaul routing and we see a small latency decrease from link technology changes, don't expect more than (say) a 5 or 10 ms latency improvement.
Yay. *Yawn*.
Some countries, thankfully, do supply heavily subsidised medication. This helps protect the infected person AND those around them.
If yours isn't one of them, I guess you're probably from America or somewhere else in the Third World :-P
Agreed, the proportion of the population who are positive (as opposed to who test positive) is indeed an important factor in determining whether test accuracy levels are acceptable.
The suitability of a test also depends on the use you're putting the test to, and whether the false negative and false positive rates are the same.
For pre-screening, in order to avoid performing a more expensive test with a very low false positive rate, a false postive rate of 50% would still be fine - but the false negative rate would have to be near-zero (at least as low as the "real" test) lest you turn people with the disease away as uninfected. Even with a 50% false positive rate you're still halving the number of tests you must perform.
On the other hand, say you've developed a test that can detect a form of cancer that's otherwise undetectable, but is treatable if detected early. The drugs required for treatment cause irreparable liver damage, particularly for people who do not have the cancer. In this case, the false positive rate must be extremely low in order to avoid harming people who're healthy and don't need treatment. However, the false negative rate may be almost anything and the test is still useful - if you identify the disease in 40% of afflicted cases tested, it's still worth using on people you suspect might have it.
In another case, if you're testing to determine (say) for a condition that might exclude someone from driving, flying a plane, etc (say a propensity for frequent narcolepsy) then you need an extremely low false negative rate to protect other people, and an extremely low false positive rate to protect the person taking the test from unnecessary exclusion. A test that's inaccurate in either direction probably isn't worth using.
And good on you.
Mac zealots, UNIX/Linux zealots, Windows zealots, and the one lonely Plan 9 zealot really all need to get a life. Deflation of their egos is generally welcomed by everybody other than them - though more often than not attempts just bounce off their mindless rhetoric, circular reasoning, and utter unshakable certainty. The more factually incorrect their beliefs the better.
The Mac people are perhaps the worst. (Note: Many, many years ago when Mac OS 7 was new I used to be one of them - argh!). They can change their story in an instant. "Intel sucks, it's slow, the PowerPC 704e/G3/G4/G5 is the best thing ever" -> "PowerPC is old and crappy, get an Intel CPU, they're great". And that's just one of the more recent examples. Grr. Suuuure, Pascal is the great new language of the future.
Then again, there's nothing quite like hearing a Linux zealot patiently explaining to someone who's having issues with Quicken on their home PC how much better off they'd be if they just install Gentoo or build Linux-from-scatch then install and configure SQL Ledger. The fact that the user in question can't even install the update to Quicken that'd fix the issue by clicking "install update" when automatically prompted doesn't seem to faze them. (This is being written on an Ubuntu box that's also compiling a test SCSI controller bugfix patch in qemu svn, by the way; I'm a Linux user but still loathe the zealots.)
Windows zealots ... well, I'm not sure I've met one. Weird, really, given that it's exactly the same sort of mix of great and awful as the other major platforms, albeit with different pluses and minuses.
Props for effort, but I think your comment probably bounced off just as thoroughly as they usually do.
Tell that to someone who's used BSD.
With BSD I have source code. I have a kernel I control. I have a window system that supports network display of applications natively. All my tools work from the command line, instead of having to do things from often-limiting GUIs. Said tools are also documented, which is a nice change from Mac OS X (where the docs for Apple tools are patchy, and rarely in the form of man pages). I can run BSD on any hardware I want instead of a restricted set of marked-up branded equipment. Oh, and did I mention the use of a sensible file system instead of HFS+ ?
The same goes for Linux.
Of course, I also have far fewer device drivers, far FAR fewer apps in many categories, less support for things like graphics tablets, and all sorts of other things than would be the case under Mac OS X (or Windows).
Argh!
Mac OS X has a POSIX subsystem based on a mixture of BSD and GNU tools, and a kernel that is in large part based on BSD's. Calling it BSD is a disservice to both BSD and Mac OS X.
Actually, there's a legal, licensed MP3 decoder available for Linux. http://www.fluendo.com/resources/fluendo_mp3.php It's open source (MIT) with binaries approved by Fraunhofer available. So you're OK even if you do stick strictly to all patent law, live in a country where such law applies to software, and require source to all code running on your system (above BIOS/firmware level).
This depends a lot on the application. An app that uses (say) a webcam, microphone, and supports sophisticated input devices like pressure-sensitive touchpads will be a lot easier to develop for just one platform. You land up writing your own abstraction layers a lot, and maintaining them is a lot of work. The better you want to integrate into the OS, the harder things get. Think file manager context menus, global hotkeys, anything like that. That said, tools like Qt, SDL, OpenAL, etc make a big difference when it comes to writing portable apps that go beyond the basic C/POSIX interfaces. They are improving all the time, too. For example, just last year it was a F**ing nightmare to embed a decent browser in a cross platform app; now it's comparatively trivial especially for Qt applications.
The issue is not that the package formats don't permit dependency specification. The problem is that the package names and version schemes are inconsistent between distros, so it's hard to know what to call the package. As such, you have to make packages of your app for each distro. That's a pain, but not actually all that bad. As someone who does both win32 and Linux development, I'd say they're both about equally excruciating.
Yes, it could be useful for examining the output of the query in non-performance terms. For complex queries I can easily see how that could be useful. That may, in fact, be the whole idea behind the tool - to help reduce or eliminate execution of grossly incorrect queries that don't do what the user wants. Tools like EXPLAIN aren't as useful for that, either, as the query looks quite different after the query optimiser is done with it. Additionally EXPLAIN output usually drops detail about specific fields, so it's not really possible to predict the results of the query from explain output alone. That said, it's quite possible to spot issues like a join without a filter.
I think you might've missed the point.
The term SELECT statement generally refers to the whole statement, including FROM, WHERE, HAVING, etc clauses.
This is pretty clear in context, as it'd be nonsensical to produce a graphical explain tool for the result field list in the SELECT clause its self.
That's why the parent said SELECT statement not SELECT clause .
As it happens the same issues regarding the need for planner knowledge etc are true for DML like INSERT, UPDATE and DELETE. It's not about SELECT at all, but rather any non-DDL query.