I agree with your points. It's interesting to note that the cost of an LED bulb that goes in an old fixture is similar to, or more expensive than, a brand-new fixture with LEDs built in!
When you design a fixture as an LED fixture, you can design it to dissipate the heat. The whole exterior of the fixture can be used as a heat sink to put heat out into the room (i.e. get it away from the LED chips). But when you design a backward-compatible bulb, you must pack those chips in a small space, and you need to put in a lot of them in all different directions. So you need a carefully-engineered design, which packs a lot of LED chips in a small space yet keeps them cool.
It's clearly better to have all the LEDs pointing in the direction you want the light to go, but old incandescent fixtures often have the bulb on its side with a reflector above it. So the carefully-engineered LED bulb that shines in all directions is now working to bounce light off a reflector, rather than just have all the LEDs shine where you want the light.
You can already buy a "can light" replacement, the Cree LR6, that has a decorative bezel that helps serve as a heat sink. It's easy to install too. I had a single can light in my home and I have already installed one of these; I love it.
So "can lights" are a solved problem, but normal light bulb fixtures are harder.
You can buy fixtures now with soldered-in LED chips. And they should last two decades, which isn't bad. But I'd like to see a standardized modular design, where power supply is one modular piece and the LEDs are mounted on another (designed to work as a heat sink). This would solve the problem someone noted, that two decades from now the fixtures you bought may no longer be made, and replacing them one at a time won't look ideally pretty.
Slightly off topic, but I recommend the novelization of Fantastic Voyage. It is the one novelization I have read that was actually better than the movie from which it was taken. This is because it was written by Isaac Asimov in his prime.
There are all sorts of weird little things in the movie that are explained in the book. Like, why can the mission only take 60 minutes? And, at the end, whatever happened to the submarine?
(There was one scene from the movie that was just too stupid to explain, so Asimov simply left it out of the novelization. There's a scene where a box is brought on board, and someone asks what is in the box. "Oh, that's our atomic particle. We are going to be so small that we can run our nuclear reactor on one particle." Yeah, no.)
Years later, Asimov wrote a sequel. I tried reading it and couldn't get through it. His writing style had changed a lot, and I didn't care for it. So I only recommend the original book.
The slide for UTF-16 clearly says that UTF-16 is the result of "encoding", not "decoding":
Actually, you are correct. Sorry, you confused me a bit. Go back to what I said earlier: a string is conceptually a sequence of Unicode codepoints, and to turn it into a filename you must encode it in a particular encoding. My greater point stands, namely that the Python terminology is completely consistent: you always encode from a string to an encoding, and you always decode from an encoding to a string. I apologize for the mistake.
Also I did experiments and the new encoding cannot produce unpaired surrogates, therefore it cannot produce all possible NTFS filenames.
Show me the code. If you really have found a problem, show me how to reproduce it.
Let me remind you that Python allows you to write literals in UTF-16, which would avoid this issue; let me also remind you that Python allows you to specify the options on encoding, so if you somehow got a Unicode string that contains surrogate characters that you need to have left alone, you can just specify the encode to not use surrogateescape.
I know a lot of people like to put filenames in text files. It is kind of useful, in fact this is supported directly by Python when you use a filename in quotes in a.py file! Yet they have made it impossible to place all possible UTF-8 filenames in a Python script unless a bytes api is used and the programmer has to write the UTF-8 code units individually as \xNN sequences, making it unreadable.
Frankly I don't care. First you said Python is broken because it's possible to make a filename with illegal characters in it; I pointed out that with os.listdir() that this case Just Works. Now you say that Python is broken because when you have a filename with illegal characters in it, the only way to make a literal in a program is to use hex escapes. If I have a filename with illegal characters in it, I'm just going to write the hex escapes; I don't have a problem with this. In other news, Python programs are slower than hand-crafted C programs. Python is really good at a lot of stuff, but not perfectly optimal at everything. You have identified a corner case where you must use ugly hex escapes in a filename literal. Okay, if that's a deal-breaker for you, don't use Python.
Your suggested solutions are just like all the other ones: basically never use Unicode at all in your Python program and use byte arrays everywhere.
Actually, no. You said that you wanted the ability to hold onto raw UTF-8 and pass it around, and I pointed out that Python lets you do that. I just want to use the provided Python API functions, which Just Work as far as I can see.
And for my own programs, so far all the filename literals have been boring, with no illegal characters in them. I've never had to write a Python program where UTF-8 wasn't adequate for all my filename literals.
Also we are back to the stupid programmer problem:
This is the underlying problem: the current behavior encourages ASCII-only use and is effectively destroying attempts to migrate to Unicode. They need to make it easy to write a reliable program that uses UTF-8 and UTF-16, which means it must not do something unexpected if a physically possible pattern is encountered in the data.
You keep saying these things, but I haven't seen any evidence.
And if you really are smarter than all the "incredible morons" working on Python, please contribute your insights on a Python mailing list, rather than just flaming here.
I don't think I'm convincing you of anything, and frankly I'm not the world's greatest expert on Python stuff, so I think I'm done with this thread. If you really care about convincing me that Python is broken, please show me the code. Thank you and have a nice day.
It is impossible to write some valid Windows NTFS filenames in UTF-8!!!! That is a serious defect.
I believe you are completely mistaken here.
In a *NIX context, filenames are sequences of bytes, and it is possible for those bytes to include values that are not legal UTF-8; Python 3.x has a scheme that escapes these illegal characters making a perfect lossless filename -> Python Unicode string -> filename conversion sequence.
In a Windows context, filenames are UTF-16, and Python 3.x will not use the surrogateescape translation. It doesn't need to. My understanding, backed up by Wikipedia, is that UTF-8 can encode every code point in all of Unicode, so there shouldn't be any valid UTF-16 file name that UTF-8 cannot encode.
So, your UTF-8 file example, Python does need to know whether the filenames are valid *NIX filenames or valid Windows filenames. But either or both cases are possible.
Note also that *NIX names and Windows names are not perfectly convertible. *NIX names are allowed to contain a colon, an asterisk, a double-quote, and other characters that are errors on Windows. (I can't think of any Windows filenames that cannot be converted to *NIX but maybe there are some?)
It is IMPOSSIBLE for UTF-8 -> Unicode -> **UTF-16** to produce all possible UTF-16 strings!
Therefore it is IMPOSSIBLE to store Windows filenames losslessly in a UTF-8 text file.
This is not my understanding, and Wikipedia seems to contradict this as well. If you really want to convince me, please show me a specific example.
I wanted to check if the translation to/from UTF-16 was lossy due to the surrogate replacements. It is not, but only because it appears that the UTF-8 encoding of 0xDC80..0xDCFF is considered "invalid" and thus turns into 3 of these codes when converted to UTF-16 rather than one.
This is exactly what I expected: the translation isn't lossy, and the only way it can be non-lossy is if the surrogate characters are escaped. I'm not seeing the problem here.
Thus it is impossible to write some valid Windows NTFS filenames in UTF-8 (actually I think it is impossible to put any of the codes 0xD800..0xDFFF into a UTF-16 filename by using "decode" as they like to call it).
You still don't seem to understand the situation. The surrogateescape feature is used when Python reads a UTF-8 filename into a Python string (and then only used for characters illegal for UTF-8). When Python writes the string back out, the translation is reversed and the original string comes back out. But if you hand-craft a "bytes" object containing valid UTF-8 that includes those surrogate characters, then pass it to the Python file system stuff, it will be used as-is.
If you hand-craft a UTF-8 string that includes characters that are illegal for UTF-8 and then try to use that on a Windows file system where the file names are stored in UTF-16, I don't know what will happen and frankly I don't care. On Windows you use valid Unicode filenames, and Python lets you do that. On *NIX you use string-of-bytes filenames, and Python lets you do that.
There is no way they are going to get the bugs out of there mess
As far as I can see, you still haven't identified any actual bugs.
This is still wrong in that you have to pass the special "surrogateescape" and use encode/decode.
In the context of handling filenames, you get this by default. As I said, I used os.listdir() and my file whose name contained a character invalid for UTF-8 was in the results, with a surrogate escape code for the illegal character; I was able to open it, rename it, or delete it (I tested all three).
In short, filenames Just Work in Python 3, despite your claims.
I want to be able to store a "Unicode" string that contains a UTF-8 error without an exception being thrown. The exception would be thrown if you attempt to translate the string to UTF-16 or look at the code points (though I also recommend there be ways to avoid the exception).
If you are reading UTF-8 characters from a file, you don't get the surrogate encoding by default; by default it raises an exception, which you could handle. But it is a simple matter to request the surrogate encoding, and then you can easily filter the resulting string and look for the surrogate encoding characters. You may disagree with the default behavior in Python 3.x but I don't think you can claim that it is broken or insane.
And! I didn't realize this until now, but Python 3 also allows you to use a "bytes" object to store raw UTF-8. You can convert a Unicode string representing a directory name to bytes (using the str.encode() method function) and then pass the bytes object to os.listdir(), and the resulting list of filenames will be bytes objects with the raw UTF-8. I believe this is exactly what you said you wanted. (So are the Python guys still "incredible morons"?)
Their problem is that they seem to think that UTF-16 (or perhaps UTF-32) is somehow "decoded" and UTF-8 is "encoded", while in fact it is the opposite, and they seem to be thrashing around trying to hide the fact they got it wrong with this filesystem stuff.
And your problem is that you haven't studied what Python does or why it does it, yet you write long rants about how wrong it is. (See, I can be all judgmental too.)
In Python 3.x, the concept is "all strings are Unicode". This means that from a Python user's point of view, a string is a sequence of Unicode code points, with an associated set of method functions. All else is implementation details. So, if you are reading a file that contains UTF-8, Python must decode the UTF-8 encoded bytes into Unicode and make the string. If you are writing a file that should be encoded as UTF-8, Python must encode the Unicode characters into UTF-8. Despite your claims, Python is completely consistent: converting from any encoding (UTF-8, UTF-16, UTF-32, Latin-1, etc.) to Unicode string is called "decoding" and converting from a string to any encoding is "encoding". See the above-linked Unicode HOWTO document.
You keep saying they "got it wrong" but I actually tested it and it Just Worked for me, so it doesn't look wrong to me.
On Unix at least a filename is a stream of bytes, and changing the "locale" should not change what file it identifies.
If you just use the Python tools for managing files, they will Just Work. If you override the Python tools and tell them to decode with the wrong codec, you will get a bad result. This is a problem because... why, exactly? Would you also say that Python "got it wrong" because if you read a UTF-8 file but tell Python to use the Latin-1 codec it won't work right?
Even on Windows with NTFS a filename is UTF-16, which is not "decoded" in their terminology,
If Python just did not complain and passed invalid UTF-8 around, we could stop using other encodings.
You are flaming pretty hard on this issue... but I don't understand why, because as far as I can understand, what you are proposing here is pretty close to what Python actually does.
Python has an encoding error handler called surrogateescape, and uses it by default in all contexts that involve filenames. Thus if you have a filename that contains an illegal character for UTF-8, Python doesn't complain but just uses a surrogate escape for that illegal character; then when the Python string is converted back to a UTF-8 bytes sequence, the surrogate is converted back to the illegal byte.
Figure out how to write something in Python that can rename a file with a "bad" filename (ie invalid UTF-8) to have a "good" filename that is valid UTF-8. import os os.rename(illegal_name, legal_name)
And that is not just hand-waving; I just did it. I created a file with a name that is illegal UTF-8, and used os.listdir() to get a list of filenames... result: no error and I got the list. I pulled the filename out of that list and passed it to os.rename()... result: no error and it renamed the file.
I'm really confused because you seem to know about this already and yet in this comment you are making these strange claims that Python can't cope with invalid characters in filenames.
There are two cases for calling print(): in your program, and interactively at the command line.
In my programs, I am okay with print() being a function, and always putting the parens. In fact, I code my Python 2.x programs that way as well to make them more portable. (This works for printing any single value, and strings using % escapes or the {} format stuff are single values. If you want to use the comma syntax for printing multiple values in Python 2.x, you can't wrap everything in parens, because then everything becomes a tuple.)
For interactive use, I itch to avoid typing parens for trivial stuff. And luckily, other people have already solved the problem. Instead of just running python to get an interpreter, run ipython, the "interactive Python" shell. Among its many cool features, it will add the parens for you on simple function calls. "Simple" means 1 argument by default; but again, strings made with % escapes or the {} format stuff are single values.
So, if you are really lazy, define a function called p() that prints its argument, and in ipython you can print values like so: p 2+3 # prints 5
And "help foo" works as you wish. By the way, here's a tip: if you want to get help on a Python keyword, you can, as long as you put it into quotes. help(int) # gets help on the int class help(def) # error because "def" is a keyword help("def") # gets help on the "def" keyword
I'm sure there is some odd interactions with the parsing of some obscure syntax that need to be figured out
I personally like how straightforward Python is: foo # you get some sort of an object foo(3) # call to that object with arg 3 foo 3 # legal in Ruby, calls foo(3); not legal Python
There are no tricky cases where you are calling the object without parens. Ruby, on the other hand, has what you want, as shown in the example above... and that means that Ruby has to have special syntax you use to get the object reference instead of calling the object.
Only one technology can deliver that: Nuclear power.
If you read the Wikipedia page I linked, you will see that the Navy is planning to use a combination of diesel generators and gas turbines. The gas turbines are good when you need a whole lot of power, but don't throttle down well; the diesels are less efficient at high power but do throttle down well, so between the two technologies you can scale up the power from a little to a lot.
these weapons are no less dangerous than a room full of conventional ammunition -- large amounts of electrical equipment failing in a contained area can wreak devastation far in excess of what a torpedo could do.
I'm not certain I am following... it sounds like you are saying that a room full of electrical equipment explodes more dangerously than a room full of gunpowder-filled brass shells or a room full of missile fuel and explosive warheads? In short, that electrical equipment explodes worse than things designed to explode? This seems counter-intuitive.
I've read a few articles about the future directions the US Navy wants to take for ship technology. Basically, they want the ship to have a huge amount of electrical generation capacity onboard, then multiple redundant busses to route the power all over. Propulsion will be giant electric motors driving propellers or waterjets. Power can also fire railguns and now lasers.
If they have multiple generators as well as multiple redundant busses the ships might not have any single spot where damage could put the ship out of commission.
Railguns and lasers also have the nice property that they don't explode when hit. A magazine full of gunpowder, or a rack of missiles with liquid fuel, could explode when hit; but railgun projectiles just sit there, and the laser doesn't even have any consumables other than the electricity.
Let's just hope they don't use Windows 8 for the power management computers.
With Windows inside the VirtualBox. Once the guests leave, revert the VirtualBox image.
With a little work, you can make a "guest" login that launches VirtualBox and can't do anything else.
On the other hand, it might be enough to make a "guest" account, and just run a script that cleans out/home/guest after the users leave: # remove all trace of guest directory rm -fr/home/guest # set up clean copy again cp -pr/whatever/guest/home
If you are using Linux Mint with MATE, your guests should be able to cope with the desktop. If you are using an "improved" desktop like GNOME Shell or Ubuntu Unity, stick with the VirtualBox running Windows.
He's not "bitching" about anything. He was asked this question
Mod parent up. The reporter asked him whether what we have now is basically the Dynabook, and he replied, in part:
For all media, the original intent was "symmetric authoring and consuming".
Isn't it crystal clear that this last and most important service is quite lacking in today's computing for the general public? Apple with the iPad and iPhone goes even further and does not allow children to download an Etoy made by another child somewhere in the world. This could not be farther from the original intentions of the entire ARPA-IPTO/PARC community in the '60s and '70s.
If you click on the link, you will find out that this isn't just a made-up Slashdot story; it was Lennart's joke. He said they are doing a replacement libc now, they plan to make systemd into an email client (a clear reference to Zawinski's Law), and they figure they will add an OS kernel someday, a gentle poke at GNU/HURD (it was right there in that post).
I'm not the biggest fan of April Fools humor, but at least in this case it was someone poking fun partially at himself.
Does adding a nasty, flamebait summary make the joke better?
In his typical fashion of replacing perfectly working software with useless broken-by-design crap, our dearest Lennart has decided that the time has come for systemd to gain an email program. He determined that the GNU libc was insufficient for the task of a dbus-enabled cpu hogging email client
Really? Really, Unknown Lamer? Did you actually think this vitriol is funny?
I'd be more worried about the thing getting a couple hundred feet and turning into a fireball, possibly setting off the nuke
Hmm, I'm not too worried about that.
As I understand it, nuclear fission bombs work by taking at least two lumps of uranium, each one sub-critical-mass by itself, and slamming them into each other really fast so that they form a single critical mass. To get the intended explosion, the lumps have to be slammed together just right, which is done by precision explosives. (I got this from an article in a magazine, so I don't know anything beyond what I wrote here.)
So an accidental nuclear explosion would involve accidentally lighting off the precision explosives, precisely. A plausible way this could happen would be for the detonator to be initiated when you didn't intend it. A missile breaking apart in the air isn't going to do it; the explosives won't go off in the correct sequence, and they will blow apart the uranium instead of fusing it into a critical mass.
If my understanding is correct, maybe even a grenade in the right place would damage the nuclear warhead enough that it never could explode properly. Uranium everywhere and no big boom.
In The Atrocity Archives there was a scene where they went to elaborate lengths to try to render a nuclear device unable to detonate, and I was really wondering why they didn't just put some explosives on one side of it and blow them up; that ought to scramble the works enough that a critical mass couldn't form properly.
Here's my problem: because H.264 is a patented technology, you can't use it without the permission of the patent holders. So maybe today they are charging a couple of pennies per individual video, but how can I trust that this won't go up significantly tomorrow?
My understanding is that the H.264 patents won't expire until somewhere around 2027 or so. That is a long time to be at the mercy of patent holders.
Also, the technology being patented is a problem for free software projects like Firefox. I would like to see at least one video codec with acceptable performance that free software can use freely. Even if H.264 was licensed free-as-in-beer, there are restrictions on it that make it impossible for free software projects to use.
Google's lawyers spent a long time looking over VP8 before Google tried to set it free. So far no challenges to VP8 have really succeeded (MPEG-LA got some money, but failed to stop VP8 or get royalties, and that really must be considered a failure for MPEG-LA). I'm hoping and expecting that this challenge will, in the end, not succeed either.
If I'm right, what happens? Then VP8 becomes a free, lower-performing alternative to H.264. H.264 retains its status as the favorite codec at Apple, all those mobile devices still have H.264 built-in, and MPEG-LA can still collect the royalties. As you noted in your post, the royalties are not unreasonable.
It will be a similar situation as Vorbis and MP3. I consider Vorbis to be a success; it didn't kill MP3, but it did provide a useful alternative, and it kept the MP3 royalties from getting completely crazy. (Vorbis is actually technically superior to MP3, so I once had hopes it might "win" but it never happened.) I expect a similar story from VP8: it will never displace H.264 as the top format, and years from now people will sneer at it for "failing" to do so... but it will give Google and other companies a bargaining chip when MPEG-LA tries to raise royalties too much. They can make a serious threat to migrate their business away from H.264 and to VP8 if the royalties go too high.
If H.264 really was the only game in town, the industry would have to pay whatever rates MPEG-LA chose to set. And in the end, that means the consumers would pay.
One of my favorite albums was recorded "direct to disk", with a vinyl cutting machine recording the performance live, and the band playing each record side straight through in one set. (The album was James Newton Howard and Friends.)
But here's the thing: they also ran a digital recorder, and the CD was made from the clean digital recording. Then they mastered the CD properly, and it's a very nice CD. I don't think it would be improved by a less-clean recording process.
Oh, my. It's been re-issued, with a new master made from the direct to disc vinyl recording! So it looks like Sheffield Labs thinks it is improved by using a less-clean recording process. No thanks, I'll keep my clean digital copy.
There is exactly one good thing about vinyl recordings: they make it impossible to really over-gain the music to where the wave forms are mangled by hard-clipping. But the alternative is to make a digital copy and just, you know, don't over-gain it.
As with tube amplifiers, there is distortion associated with vinyl records that some people like. The solution is to make a digital filter that simulates this distortion. I helped write such a filter, and I actually like using it when I listen to music with headphones. But I don't want this sort of distortion impressed forever upon the music at the time of recording!
We have the technology to just make a clean copy of the artist's performance. Once that is done, the album can be mastered, and remastered. Heck, record it with a clean digital process and then carve it into vinyl if you want to... just keep the clean digital copy around, so that someday you can change your mind and release a version without the analog distortion.
I'm not a lawyer, but I think I am "anyone who follows codecs" and I'm not as sure of this as you are.
A lot of patents are very narrow. Many of the famous software patents, like One-Click, are disturbingly broad, but many of the patents related to video compression are narrow. The VP8 strategy, as I understand it, was to study the patents and make sure that everything in VP8 was just different enough that it doesn't infringe.
This means that VP8 is an inferior codec compared to H.264; some of the patented techniques really are better. However, it should be a "good enough" codec for most purposes.
Their "work around" was to give identical technologies different names and put their fingers into their ears screaming "LA LA LA LA LA" denying any patent infringement.
-1, flamebait.
When they realized this wasn't going to work, Google finally licensed the patents from MPEG LA.
I don't purport to have a secret pipeline into Google management and be able to tell what they were thinking. Do you have such a secret pipeline?
An equally workable summary is: Google had an opportunity to throw a few dollars at MPEG-LA and end the FUD forever, and they did so. Even if Google was convinced they could win on the merits in court, it was worth something to just make the problems vanish.
Note that Google specifically has not agreed that there was any patent infringement:
"This agreement is not an acknowledgment that the licensed techniques read on VP8. The purpose of this agreement is meant to provide further and stronger reassurance to implementors of VP8," said Google executive Serge Lachapelle in a post on a forum.
P.S. I am somewhat bemused by your tone. It seems you are eager to see VP8 get shackled by patents... why is that? Are you so certain that Google is a bad actor here that you just want to see Google get punished? Or do you hate freedom, or what exactly?
Please for one moment stipulate that VP8 contains technologies that are just enough different from the patents that they don't infringe... would you still have a problem with VP8 in that case?
MPEG-LA has claimed that it is impossible to make a video codec without infringing patents, because all the fundamental technologies are patented... is this, in your opinion, a good situation?
I'm personally cheering for Google in all this. They spent over $100 million to buy On2, just so they could set VP8 free. As far as I can tell, they did this for two reasons:
So they could ensure that their costs would not skyrocket on YouTube. They weren't looking forward to choosing between paying possibly-ruinous patent royalties, or using lame video codecs and burning far too much bandwidth.
To help keep us all a bit more free. Lots of the people who work at Google are geeks like us and value freedom as we do.
Considering the lyrical content of what tops the charts, I think the music industry's assumption that their customers are idiots is quite correct.
It's hard to disagree with your point. But the problem is that the music industry is remastering old music to be loud, as well as mastering the new music to be loud. I am now deeply suspicious when I see "newly remastered!" on a CD label. Once upon a time that was a promise of improved quality; these days it might mean a "loud" master that is actually worse than the original. And they are doing this, not just for death metal bands but for everything. For example, a Billy Joel pop album is not improved by being overcompressed, but:
I would pay more for audio tracks that are mastered properly.
Far too much of the music released these days is mastered to sound "loud". A sound-level compressor removes the dynamic range, and then the music is gained up about as high as possible, or sometimes higher than that (gained so high there is hard-clipping).
In the best case, the dynamic range is gone and the music loses some of the drama and impact it should have had. In the worst case, the sine waves are hard-clipped into square waves, which sounds terrible. Hard-clipping adds unpleasant harmonics and distortion and you definitely can hear this.
I promise you that a properly mastered track at 16-bit/44.1 kHz will sound dramatically better than a poorly mastered one at 24-bit/96 kHz. Mastering trumps format.
So if they are going to the trouble to make 24-bit/96 kHz tracks, I'm hoping that they will let the mastering engineers do their jobs properly! If they do, I would pay the extra money and bandwidth to buy the music in the higher-quality format.
The music industry is convinced that most of their customers are idiots, unconcerned about sound quality, who can be distracted by shiny things or loud noises; so they try to make every album as loud as possible. But maybe, just maybe, they will be willing to try something different with the high-quality downloads.
SemiAccurate reported that HP was very annoyed by the Microsoft Surface, was dropping any plans for "WART" devices ("Windows on ARM"), and would embrace Android.
Start out making a toy for rich people. Low volume high cost production, make an expensive toy, make a profit and learn.
Then make a more-affordable car for upper-middle-class and above. Higher volume lower cost production, make a car that fits in the luxury car category like high-end BMW, make a profit and learn.
Next, they plan to make an even-more-affordable care that middle-class can afford. Using everything they have learned, make a car that is inexpensive enough that there is a chance the middle class will buy it.
Two decades from now, if they continue this, they may be competing with Ford and Honda. And good for them if the can make it.
Right now, it just isn't possible for them to make an electric car that they can sell for the cost of a Honda Accord. They could make something that they could sell at that price, but not a no-compromises all-around car, which is what they want to sell.
I think Tesla has accepted some government loans or grants, but mostly they are just following a plan that makes money, and I approve of that. They are selling outstanding electric cars today, and making a profit; and they have plans to get the cost down in the future.
The inevitable objection raised, is that the apparently closed system produced by this arrangement cannot result in an output force, but will merely produce strain within the waveguide walls. However, this ignores Einstein's Special Law of Relativity in which separate frames of reference have to be applied at velocities approaching the speed of light. Thus the system of EM wave and waveguide can be regarded as an open system, with the EM wave and the waveguide having separate frames of reference.
A similar approach is necessary to explain the principle of the laser gyroscope, where open system attitude information is obtained from an apparently closed system device.
That last paragraph intrigues me. Could someone who understands ring laser physics comment on this?
I want this EmDrive to be true, but I'll wait and see. On YouTube I saw a video of a prototype EmDrive rotating itself, but even if it's not fake I wonder if they have accounted for magnetic effects.
I want this to be true because space exploration would be tremendously faster if the spacecraft could accelerate the whole way without ever running out of reaction mass. Even if the acceleration was low, continuous acceleration would build to really fast velocities.
Slashdot Mirror
I've already seen a movie using similar effects: Captain EO
I'd rather see a low-budget 2D movie with a good plot than an expensively produced 3D movie with smoke effects and lasers but with a poor plot.
(I do have some hope that Iron Man 3 will be worth watching on its own merits.)
I agree with your points. It's interesting to note that the cost of an LED bulb that goes in an old fixture is similar to, or more expensive than, a brand-new fixture with LEDs built in!
When you design a fixture as an LED fixture, you can design it to dissipate the heat. The whole exterior of the fixture can be used as a heat sink to put heat out into the room (i.e. get it away from the LED chips). But when you design a backward-compatible bulb, you must pack those chips in a small space, and you need to put in a lot of them in all different directions. So you need a carefully-engineered design, which packs a lot of LED chips in a small space yet keeps them cool.
It's clearly better to have all the LEDs pointing in the direction you want the light to go, but old incandescent fixtures often have the bulb on its side with a reflector above it. So the carefully-engineered LED bulb that shines in all directions is now working to bounce light off a reflector, rather than just have all the LEDs shine where you want the light.
You can already buy a "can light" replacement, the Cree LR6, that has a decorative bezel that helps serve as a heat sink. It's easy to install too. I had a single can light in my home and I have already installed one of these; I love it.
So "can lights" are a solved problem, but normal light bulb fixtures are harder.
You can buy fixtures now with soldered-in LED chips. And they should last two decades, which isn't bad. But I'd like to see a standardized modular design, where power supply is one modular piece and the LEDs are mounted on another (designed to work as a heat sink). This would solve the problem someone noted, that two decades from now the fixtures you bought may no longer be made, and replacing them one at a time won't look ideally pretty.
Slightly off topic, but I recommend the novelization of Fantastic Voyage. It is the one novelization I have read that was actually better than the movie from which it was taken. This is because it was written by Isaac Asimov in his prime.
There are all sorts of weird little things in the movie that are explained in the book. Like, why can the mission only take 60 minutes? And, at the end, whatever happened to the submarine?
(There was one scene from the movie that was just too stupid to explain, so Asimov simply left it out of the novelization. There's a scene where a box is brought on board, and someone asks what is in the box. "Oh, that's our atomic particle. We are going to be so small that we can run our nuclear reactor on one particle." Yeah, no.)
Years later, Asimov wrote a sequel. I tried reading it and couldn't get through it. His writing style had changed a lot, and I didn't care for it. So I only recommend the original book.
The slide for UTF-16 clearly says that UTF-16 is the result of "encoding", not "decoding":
Actually, you are correct. Sorry, you confused me a bit. Go back to what I said earlier: a string is conceptually a sequence of Unicode codepoints, and to turn it into a filename you must encode it in a particular encoding. My greater point stands, namely that the Python terminology is completely consistent: you always encode from a string to an encoding, and you always decode from an encoding to a string. I apologize for the mistake.
Also I did experiments and the new encoding cannot produce unpaired surrogates, therefore it cannot produce all possible NTFS filenames.
Show me the code. If you really have found a problem, show me how to reproduce it.
Let me remind you that Python allows you to write literals in UTF-16, which would avoid this issue; let me also remind you that Python allows you to specify the options on encoding, so if you somehow got a Unicode string that contains surrogate characters that you need to have left alone, you can just specify the encode to not use surrogateescape.
I know a lot of people like to put filenames in text files. It is kind of useful, in fact this is supported directly by Python when you use a filename in quotes in a .py file! Yet they have made it impossible to place all possible UTF-8 filenames in a Python script unless a bytes api is used and the programmer has to write the UTF-8 code units individually as \xNN sequences, making it unreadable.
Frankly I don't care. First you said Python is broken because it's possible to make a filename with illegal characters in it; I pointed out that with os.listdir() that this case Just Works. Now you say that Python is broken because when you have a filename with illegal characters in it, the only way to make a literal in a program is to use hex escapes. If I have a filename with illegal characters in it, I'm just going to write the hex escapes; I don't have a problem with this. In other news, Python programs are slower than hand-crafted C programs. Python is really good at a lot of stuff, but not perfectly optimal at everything. You have identified a corner case where you must use ugly hex escapes in a filename literal. Okay, if that's a deal-breaker for you, don't use Python.
Your suggested solutions are just like all the other ones: basically never use Unicode at all in your Python program and use byte arrays everywhere.
Actually, no. You said that you wanted the ability to hold onto raw UTF-8 and pass it around, and I pointed out that Python lets you do that. I just want to use the provided Python API functions, which Just Work as far as I can see.
And for my own programs, so far all the filename literals have been boring, with no illegal characters in them. I've never had to write a Python program where UTF-8 wasn't adequate for all my filename literals.
Also we are back to the stupid programmer problem:
This is the underlying problem: the current behavior encourages ASCII-only use and is effectively destroying attempts to migrate to Unicode. They need to make it easy to write a reliable program that uses UTF-8 and UTF-16, which means it must not do something unexpected if a physically possible pattern is encountered in the data.
You keep saying these things, but I haven't seen any evidence.
And if you really are smarter than all the "incredible morons" working on Python, please contribute your insights on a Python mailing list, rather than just flaming here.
I don't think I'm convincing you of anything, and frankly I'm not the world's greatest expert on Python stuff, so I think I'm done with this thread. If you really care about convincing me that Python is broken, please show me the code. Thank you and have a nice day.
It is impossible to write some valid Windows NTFS filenames in UTF-8!!!! That is a serious defect.
I believe you are completely mistaken here.
In a *NIX context, filenames are sequences of bytes, and it is possible for those bytes to include values that are not legal UTF-8; Python 3.x has a scheme that escapes these illegal characters making a perfect lossless filename -> Python Unicode string -> filename conversion sequence.
In a Windows context, filenames are UTF-16, and Python 3.x will not use the surrogateescape translation. It doesn't need to. My understanding, backed up by Wikipedia, is that UTF-8 can encode every code point in all of Unicode, so there shouldn't be any valid UTF-16 file name that UTF-8 cannot encode.
So, your UTF-8 file example, Python does need to know whether the filenames are valid *NIX filenames or valid Windows filenames. But either or both cases are possible.
Note also that *NIX names and Windows names are not perfectly convertible. *NIX names are allowed to contain a colon, an asterisk, a double-quote, and other characters that are errors on Windows. (I can't think of any Windows filenames that cannot be converted to *NIX but maybe there are some?)
It is IMPOSSIBLE for UTF-8 -> Unicode -> **UTF-16** to produce all possible UTF-16 strings!
Therefore it is IMPOSSIBLE to store Windows filenames losslessly in a UTF-8 text file.
This is not my understanding, and Wikipedia seems to contradict this as well. If you really want to convince me, please show me a specific example.
I wanted to check if the translation to/from UTF-16 was lossy due to the surrogate replacements. It is not, but only because it appears that the UTF-8 encoding of 0xDC80..0xDCFF is considered "invalid" and thus turns into 3 of these codes when converted to UTF-16 rather than one.
This is exactly what I expected: the translation isn't lossy, and the only way it can be non-lossy is if the surrogate characters are escaped. I'm not seeing the problem here.
Thus it is impossible to write some valid Windows NTFS filenames in UTF-8 (actually I think it is impossible to put any of the codes 0xD800..0xDFFF into a UTF-16 filename by using "decode" as they like to call it).
You still don't seem to understand the situation. The surrogateescape feature is used when Python reads a UTF-8 filename into a Python string (and then only used for characters illegal for UTF-8). When Python writes the string back out, the translation is reversed and the original string comes back out. But if you hand-craft a "bytes" object containing valid UTF-8 that includes those surrogate characters, then pass it to the Python file system stuff, it will be used as-is.
If you hand-craft a UTF-8 string that includes characters that are illegal for UTF-8 and then try to use that on a Windows file system where the file names are stored in UTF-16, I don't know what will happen and frankly I don't care. On Windows you use valid Unicode filenames, and Python lets you do that. On *NIX you use string-of-bytes filenames, and Python lets you do that.
There is no way they are going to get the bugs out of there mess
As far as I can see, you still haven't identified any actual bugs.
This is still wrong in that you have to pass the special "surrogateescape" and use encode/decode.
In the context of handling filenames, you get this by default. As I said, I used os.listdir() and my file whose name contained a character invalid for UTF-8 was in the results, with a surrogate escape code for the illegal character; I was able to open it, rename it, or delete it (I tested all three).
In short, filenames Just Work in Python 3, despite your claims.
I want to be able to store a "Unicode" string that contains a UTF-8 error without an exception being thrown. The exception would be thrown if you attempt to translate the string to UTF-16 or look at the code points (though I also recommend there be ways to avoid the exception).
If you are reading UTF-8 characters from a file, you don't get the surrogate encoding by default; by default it raises an exception, which you could handle. But it is a simple matter to request the surrogate encoding, and then you can easily filter the resulting string and look for the surrogate encoding characters. You may disagree with the default behavior in Python 3.x but I don't think you can claim that it is broken or insane.
And! I didn't realize this until now, but Python 3 also allows you to use a "bytes" object to store raw UTF-8. You can convert a Unicode string representing a directory name to bytes (using the str.encode() method function) and then pass the bytes object to os.listdir(), and the resulting list of filenames will be bytes objects with the raw UTF-8. I believe this is exactly what you said you wanted. (So are the Python guys still "incredible morons"?)
http://docs.python.org/3/howto/unicode.html#unicode-filenames
Their problem is that they seem to think that UTF-16 (or perhaps UTF-32) is somehow "decoded" and UTF-8 is "encoded", while in fact it is the opposite, and they seem to be thrashing around trying to hide the fact they got it wrong with this filesystem stuff.
And your problem is that you haven't studied what Python does or why it does it, yet you write long rants about how wrong it is. (See, I can be all judgmental too.)
In Python 3.x, the concept is "all strings are Unicode". This means that from a Python user's point of view, a string is a sequence of Unicode code points, with an associated set of method functions. All else is implementation details. So, if you are reading a file that contains UTF-8, Python must decode the UTF-8 encoded bytes into Unicode and make the string. If you are writing a file that should be encoded as UTF-8, Python must encode the Unicode characters into UTF-8. Despite your claims, Python is completely consistent: converting from any encoding (UTF-8, UTF-16, UTF-32, Latin-1, etc.) to Unicode string is called "decoding" and converting from a string to any encoding is "encoding". See the above-linked Unicode HOWTO document.
You keep saying they "got it wrong" but I actually tested it and it Just Worked for me, so it doesn't look wrong to me.
On Unix at least a filename is a stream of bytes, and changing the "locale" should not change what file it identifies.
If you just use the Python tools for managing files, they will Just Work. If you override the Python tools and tell them to decode with the wrong codec, you will get a bad result. This is a problem because... why, exactly? Would you also say that Python "got it wrong" because if you read a UTF-8 file but tell Python to use the Latin-1 codec it won't work right?
Even on Windows with NTFS a filename is UTF-16, which is not "decoded" in their terminology,
No, really, it is "decoded" in their terminology.
http://farmdev.com/talks/unicode/
If Python just did not complain and passed invalid UTF-8 around, we could stop using other encodings.
You are flaming pretty hard on this issue... but I don't understand why, because as far as I can understand, what you are proposing here is pretty close to what Python actually does.
Python has an encoding error handler called surrogateescape, and uses it by default in all contexts that involve filenames. Thus if you have a filename that contains an illegal character for UTF-8, Python doesn't complain but just uses a surrogate escape for that illegal character; then when the Python string is converted back to a UTF-8 bytes sequence, the surrogate is converted back to the illegal byte.
A nice discussion with a code sample in the PEP: http://www.python.org/dev/peps/pep-0383/
Figure out how to write something in Python that can rename a file with a "bad" filename (ie invalid UTF-8) to have a "good" filename that is valid UTF-8.
import os
os.rename(illegal_name, legal_name)
And that is not just hand-waving; I just did it. I created a file with a name that is illegal UTF-8, and used os.listdir() to get a list of filenames... result: no error and I got the list. I pulled the filename out of that list and passed it to os.rename()... result: no error and it renamed the file.
I'm really confused because you seem to know about this already and yet in this comment you are making these strange claims that Python can't cope with invalid characters in filenames.
There are two cases for calling print(): in your program, and interactively at the command line.
In my programs, I am okay with print() being a function, and always putting the parens. In fact, I code my Python 2.x programs that way as well to make them more portable. (This works for printing any single value, and strings using % escapes or the {} format stuff are single values. If you want to use the comma syntax for printing multiple values in Python 2.x, you can't wrap everything in parens, because then everything becomes a tuple.)
For interactive use, I itch to avoid typing parens for trivial stuff. And luckily, other people have already solved the problem. Instead of just running python to get an interpreter, run ipython, the "interactive Python" shell. Among its many cool features, it will add the parens for you on simple function calls. "Simple" means 1 argument by default; but again, strings made with % escapes or the {} format stuff are single values.
So, if you are really lazy, define a function called p() that prints its argument, and in ipython you can print values like so: p 2+3 # prints 5
And "help foo" works as you wish. By the way, here's a tip: if you want to get help on a Python keyword, you can, as long as you put it into quotes.
help(int) # gets help on the int class
help(def) # error because "def" is a keyword
help("def") # gets help on the "def" keyword
I'm sure there is some odd interactions with the parsing of some obscure syntax that need to be figured out
I personally like how straightforward Python is:
foo # you get some sort of an object
foo(3) # call to that object with arg 3
foo 3 # legal in Ruby, calls foo(3); not legal Python
There are no tricky cases where you are calling the object without parens. Ruby, on the other hand, has what you want, as shown in the example above... and that means that Ruby has to have special syntax you use to get the object reference instead of calling the object.
Only one technology can deliver that: Nuclear power.
If you read the Wikipedia page I linked, you will see that the Navy is planning to use a combination of diesel generators and gas turbines. The gas turbines are good when you need a whole lot of power, but don't throttle down well; the diesels are less efficient at high power but do throttle down well, so between the two technologies you can scale up the power from a little to a lot.
http://en.wikipedia.org/wiki/Integrated_electric_propulsion
these weapons are no less dangerous than a room full of conventional ammunition -- large amounts of electrical equipment failing in a contained area can wreak devastation far in excess of what a torpedo could do.
I'm not certain I am following... it sounds like you are saying that a room full of electrical equipment explodes more dangerously than a room full of gunpowder-filled brass shells or a room full of missile fuel and explosive warheads? In short, that electrical equipment explodes worse than things designed to explode? This seems counter-intuitive.
I've read a few articles about the future directions the US Navy wants to take for ship technology. Basically, they want the ship to have a huge amount of electrical generation capacity onboard, then multiple redundant busses to route the power all over. Propulsion will be giant electric motors driving propellers or waterjets. Power can also fire railguns and now lasers.
If they have multiple generators as well as multiple redundant busses the ships might not have any single spot where damage could put the ship out of commission.
http://en.wikipedia.org/wiki/Integrated_electric_propulsion
Railguns and lasers also have the nice property that they don't explode when hit. A magazine full of gunpowder, or a rack of missiles with liquid fuel, could explode when hit; but railgun projectiles just sit there, and the laser doesn't even have any consumables other than the electricity.
Let's just hope they don't use Windows 8 for the power management computers.
With Windows inside the VirtualBox. Once the guests leave, revert the VirtualBox image.
With a little work, you can make a "guest" login that launches VirtualBox and can't do anything else.
On the other hand, it might be enough to make a "guest" account, and just run a script that cleans out /home/guest after the users leave:
/home/guest /whatever/guest /home
# remove all trace of guest directory
rm -fr
# set up clean copy again
cp -pr
If you are using Linux Mint with MATE, your guests should be able to cope with the desktop. If you are using an "improved" desktop like GNOME Shell or Ubuntu Unity, stick with the VirtualBox running Windows.
He's not "bitching" about anything. He was asked this question
Mod parent up. The reporter asked him whether what we have now is basically the Dynabook, and he replied, in part:
He didn't even use the word "betray" in any form.
If you click on the link, you will find out that this isn't just a made-up Slashdot story; it was Lennart's joke. He said they are doing a replacement libc now, they plan to make systemd into an email client (a clear reference to Zawinski's Law), and they figure they will add an OS kernel someday, a gentle poke at GNU/HURD (it was right there in that post).
I'm not the biggest fan of April Fools humor, but at least in this case it was someone poking fun partially at himself.
Does adding a nasty, flamebait summary make the joke better?
Really? Really, Unknown Lamer? Did you actually think this vitriol is funny?
I'd be more worried about the thing getting a couple hundred feet and turning into a fireball, possibly setting off the nuke
Hmm, I'm not too worried about that.
As I understand it, nuclear fission bombs work by taking at least two lumps of uranium, each one sub-critical-mass by itself, and slamming them into each other really fast so that they form a single critical mass. To get the intended explosion, the lumps have to be slammed together just right, which is done by precision explosives. (I got this from an article in a magazine, so I don't know anything beyond what I wrote here.)
So an accidental nuclear explosion would involve accidentally lighting off the precision explosives, precisely. A plausible way this could happen would be for the detonator to be initiated when you didn't intend it. A missile breaking apart in the air isn't going to do it; the explosives won't go off in the correct sequence, and they will blow apart the uranium instead of fusing it into a critical mass.
If my understanding is correct, maybe even a grenade in the right place would damage the nuclear warhead enough that it never could explode properly. Uranium everywhere and no big boom.
In The Atrocity Archives there was a scene where they went to elaborate lengths to try to render a nuclear device unable to detonate, and I was really wondering why they didn't just put some explosives on one side of it and blow them up; that ought to scramble the works enough that a critical mass couldn't form properly.
Here's my problem: because H.264 is a patented technology, you can't use it without the permission of the patent holders. So maybe today they are charging a couple of pennies per individual video, but how can I trust that this won't go up significantly tomorrow?
My understanding is that the H.264 patents won't expire until somewhere around 2027 or so. That is a long time to be at the mercy of patent holders.
Also, the technology being patented is a problem for free software projects like Firefox. I would like to see at least one video codec with acceptable performance that free software can use freely. Even if H.264 was licensed free-as-in-beer, there are restrictions on it that make it impossible for free software projects to use.
Google's lawyers spent a long time looking over VP8 before Google tried to set it free. So far no challenges to VP8 have really succeeded (MPEG-LA got some money, but failed to stop VP8 or get royalties, and that really must be considered a failure for MPEG-LA). I'm hoping and expecting that this challenge will, in the end, not succeed either.
If I'm right, what happens? Then VP8 becomes a free, lower-performing alternative to H.264. H.264 retains its status as the favorite codec at Apple, all those mobile devices still have H.264 built-in, and MPEG-LA can still collect the royalties. As you noted in your post, the royalties are not unreasonable.
It will be a similar situation as Vorbis and MP3. I consider Vorbis to be a success; it didn't kill MP3, but it did provide a useful alternative, and it kept the MP3 royalties from getting completely crazy. (Vorbis is actually technically superior to MP3, so I once had hopes it might "win" but it never happened.) I expect a similar story from VP8: it will never displace H.264 as the top format, and years from now people will sneer at it for "failing" to do so... but it will give Google and other companies a bargaining chip when MPEG-LA tries to raise royalties too much. They can make a serious threat to migrate their business away from H.264 and to VP8 if the royalties go too high.
If H.264 really was the only game in town, the industry would have to pay whatever rates MPEG-LA chose to set. And in the end, that means the consumers would pay.
One of my favorite albums was recorded "direct to disk", with a vinyl cutting machine recording the performance live, and the band playing each record side straight through in one set. (The album was James Newton Howard and Friends.)
But here's the thing: they also ran a digital recorder, and the CD was made from the clean digital recording. Then they mastered the CD properly, and it's a very nice CD. I don't think it would be improved by a less-clean recording process.
Oh, my. It's been re-issued, with a new master made from the direct to disc vinyl recording! So it looks like Sheffield Labs thinks it is improved by using a less-clean recording process. No thanks, I'll keep my clean digital copy.
There is exactly one good thing about vinyl recordings: they make it impossible to really over-gain the music to where the wave forms are mangled by hard-clipping. But the alternative is to make a digital copy and just, you know, don't over-gain it.
As with tube amplifiers, there is distortion associated with vinyl records that some people like. The solution is to make a digital filter that simulates this distortion. I helped write such a filter, and I actually like using it when I listen to music with headphones. But I don't want this sort of distortion impressed forever upon the music at the time of recording!
We have the technology to just make a clean copy of the artist's performance. Once that is done, the album can be mastered, and remastered. Heck, record it with a clean digital process and then carve it into vinyl if you want to... just keep the clean digital copy around, so that someday you can change your mind and release a version without the analog distortion.
patent infringement is an almost certainty.
I'm not a lawyer, but I think I am "anyone who follows codecs" and I'm not as sure of this as you are.
A lot of patents are very narrow. Many of the famous software patents, like One-Click, are disturbingly broad, but many of the patents related to video compression are narrow. The VP8 strategy, as I understand it, was to study the patents and make sure that everything in VP8 was just different enough that it doesn't infringe.
This means that VP8 is an inferior codec compared to H.264; some of the patented techniques really are better. However, it should be a "good enough" codec for most purposes.
Their "work around" was to give identical technologies different names and put their fingers into their ears screaming "LA LA LA LA LA" denying any patent infringement.
-1, flamebait.
When they realized this wasn't going to work, Google finally licensed the patents from MPEG LA.
I don't purport to have a secret pipeline into Google management and be able to tell what they were thinking. Do you have such a secret pipeline?
An equally workable summary is: Google had an opportunity to throw a few dollars at MPEG-LA and end the FUD forever, and they did so. Even if Google was convinced they could win on the merits in court, it was worth something to just make the problems vanish.
Note that Google specifically has not agreed that there was any patent infringement:
Source: http://www.pcworld.com/article/2030241/google-licenses-video-codec-from-mpeg-la-to-bolster-vp8.html
P.S. I am somewhat bemused by your tone. It seems you are eager to see VP8 get shackled by patents... why is that? Are you so certain that Google is a bad actor here that you just want to see Google get punished? Or do you hate freedom, or what exactly?
Please for one moment stipulate that VP8 contains technologies that are just enough different from the patents that they don't infringe... would you still have a problem with VP8 in that case?
MPEG-LA has claimed that it is impossible to make a video codec without infringing patents, because all the fundamental technologies are patented... is this, in your opinion, a good situation?
I'm personally cheering for Google in all this. They spent over $100 million to buy On2, just so they could set VP8 free. As far as I can tell, they did this for two reasons:
Considering the lyrical content of what tops the charts, I think the music industry's assumption that their customers are idiots is quite correct.
It's hard to disagree with your point. But the problem is that the music industry is remastering old music to be loud, as well as mastering the new music to be loud. I am now deeply suspicious when I see "newly remastered!" on a CD label. Once upon a time that was a promise of improved quality; these days it might mean a "loud" master that is actually worse than the original. And they are doing this, not just for death metal bands but for everything. For example, a Billy Joel pop album is not improved by being overcompressed, but:
http://www.youtube.com/watch?v=3TlQo9k827c
I would pay more for audio tracks that are mastered properly.
Far too much of the music released these days is mastered to sound "loud". A sound-level compressor removes the dynamic range, and then the music is gained up about as high as possible, or sometimes higher than that (gained so high there is hard-clipping).
In the best case, the dynamic range is gone and the music loses some of the drama and impact it should have had. In the worst case, the sine waves are hard-clipped into square waves, which sounds terrible. Hard-clipping adds unpleasant harmonics and distortion and you definitely can hear this.
I promise you that a properly mastered track at 16-bit/44.1 kHz will sound dramatically better than a poorly mastered one at 24-bit/96 kHz. Mastering trumps format.
So if they are going to the trouble to make 24-bit/96 kHz tracks, I'm hoping that they will let the mastering engineers do their jobs properly! If they do, I would pay the extra money and bandwidth to buy the music in the higher-quality format.
The music industry is convinced that most of their customers are idiots, unconcerned about sound quality, who can be distracted by shiny things or loud noises; so they try to make every album as loud as possible. But maybe, just maybe, they will be willing to try something different with the high-quality downloads.
http://en.wikipedia.org/wiki/Loudness_war
SemiAccurate reported that HP was very annoyed by the Microsoft Surface, was dropping any plans for "WART" devices ("Windows on ARM"), and would embrace Android.
http://semiaccurate.com/2012/06/29/hp-said-to-dump-microsoft-over-surface/
CEO, Tim Poultney: All right, we'll call it a draw.
http://www.youtube.com/watch?v=zKhEw7nD9C4
The only issue with Tesla is the absurd price.
I am a fan of Tesla's business plan.
Start out making a toy for rich people. Low volume high cost production, make an expensive toy, make a profit and learn.
Then make a more-affordable car for upper-middle-class and above. Higher volume lower cost production, make a car that fits in the luxury car category like high-end BMW, make a profit and learn.
Next, they plan to make an even-more-affordable care that middle-class can afford. Using everything they have learned, make a car that is inexpensive enough that there is a chance the middle class will buy it.
Two decades from now, if they continue this, they may be competing with Ford and Honda. And good for them if the can make it.
Right now, it just isn't possible for them to make an electric car that they can sell for the cost of a Honda Accord. They could make something that they could sell at that price, but not a no-compromises all-around car, which is what they want to sell.
I think Tesla has accepted some government loans or grants, but mostly they are just following a plan that makes money, and I approve of that. They are selling outstanding electric cars today, and making a profit; and they have plans to get the cost down in the future.
steveha
I want it to be true, but I'd bet against it:
http://xkcd.com/955/
http://emdrive.com/principle.html
That last paragraph intrigues me. Could someone who understands ring laser physics comment on this?
I want this EmDrive to be true, but I'll wait and see. On YouTube I saw a video of a prototype EmDrive rotating itself, but even if it's not fake I wonder if they have accounted for magnetic effects.
I want this to be true because space exploration would be tremendously faster if the spacecraft could accelerate the whole way without ever running out of reaction mass. Even if the acceleration was low, continuous acceleration would build to really fast velocities.