|
|
I agree that a distro using Debian packages and APT really ought to be dist-upgradeable. It's lame that it's not.
But the Mint guys are the ones working hardest to let me have the kind of desktop I prefer, so I'm willing to cut them some slack.
You can avoid some pain if you set your computer up properly. Put
I'm certain that MST3K's producers made fully sure that the rights to play the movie in syndication were fully paid up
Yes, MST3K made sure they had a legal ability to do what they were doing. Cinematic Titanic continues this tradition. This is one reason why the movies they show tend to be bad: bad movies are cheap to license.
That's the brilliant part about Rifftrax. Since they are not redistributing the movie, they don't need rights. Thus they can do any movie they want, including Star Wars movies, Lord of the Rings, anything. They don't have to pay anything and they don't need to get permission first. (I don't think George Lucas would give permission to Rifftrax to mercilessly rip Episode 1...)
I'm just waiting for home Blu-Ray players to start offering an option to play an externally-downloaded audio track while playing a disc, or for AppleTV sort of products to do the same for general media files. There is no technical reason why this could not be done, and it would mean that when you pause the movie the Rifftrax pauses as well, much more convenient for the user.
A good LP-er doesn't just play the game, their value is in their commentary and jokes as they play the game.
I've never heard of this, but I believe you. My favorite podcast, Spilled Milk, is really funny and I think those guys would be just as funny if they stopped talking about food and started talking about some other topic.
Would you please post a link or two with some of your favorite "episodes" of LP?
For Intel to "win" the "mobile war" as the headline suggests, Intel would have to get the mobile device market to adopt proprietary Intel parts that only Intel can sell. Otherwise, Intel is just another vendor, and the mobile device makers can buy from Intel or not at their whim; Intel just being one of a group of commodity providers is not what Intel considers a "win".
I've said it before: Apple will never lock themselves in with Intel.
wind is intermittent; but it doesn't melt down, and storage can be done with hydro, pumped hydro or electric cars
But you need to plan to replace the wind turbines about every 12 years, and this cost must be factored in to the cost of the power.
Hydro is mature. All the good locations already have hydro plants; and environmentalists are trying to get existing hydro plants torn out to benefit river wildlife, so just forget about building new hydro plants.
I'm pretty sure pumped hydro storage is in a similar situation... you need a giant reservoir uphill of a source of lots of water you can pump. Where can you build a new one of these, and will the environmentalists approve?
Using a decentralized group of electric cars as an energy-storage system is an interesting idea, but I don't think you can dependably store very much that way in the near future.
I have hopes for molten-salt solar plants, which can keep producing power after the sun goes down because the salt holds so much heat. And it would be cool if we could work out a good way to use hydrogen to store excess energy from wind or solar... but it takes a lot of electricity to strip hydrogen out of water, and hydrogen is tricky to store.
And just as you will face opposition to building more hydro, you will face opposition to building solar in the desert.
http://e360.yale.edu/feature/its_green_against_green_in_mojave_desert_solar_battle/2236/
Nuclear is more expensive than wind, and is also poor at load following; you normally find nuclear needs hydro as well; because it's so expensive to build it runs flat out and then the hydro does the load following- nuclear is better for baseload.
I agree with your final statement; nuclear is indeed better for base load and not good at load-following. But probably natural gas is a better near-term way to reliably follow loads.
By all means get renewables into the mix, but don't make the same mistake the U.K. made, wasting huge sums of money on a system that doesn't work very well. (Right when demand is most heavy in winter, the wind farms stop producing. Quote: "In winter, when the most intense cold period coincides with a high pressure front, most wind turbines do not work.")
http://www.thisismoney.co.uk/money/article-2008055/Energy-giants-want-billions-windfarms.html
One no-brainer idea: homes and businesses in warm places (Arizona, Florida, Texas, etc.) should have solar panels on the roof. This will produce peak power during peak demand times (when everyone is running the air conditioning, the sun will be shining). This is only a tiny part of the overall energy picture, though, and will happen on its own as the cost of solar panels keeps falling.
after killing off regulations, the large corporations would have an even larger stranglehold on the marketplace, as there would be no anti-trust laws to keep them from colluding, price-fixing, etc. and any competitor who tried to enter the field would be crushed before they could get a foothold.
This sounds scary, but the reality is that a burdensome regulatory system favors large entrenched companies over start-ups. Back when Microsoft was smaller, they didn't like government, but these days they have a ton of lobbyists in D.C. just like every other major company.
Do you remember the days when IBM was "the evil empire" and ruled computing with an iron fist? Tell me, which anti-trust law was used to take them down? Oh wait, that didn't happen. IBM fought the anti-trust courts to a stand-still until the Reagan administration just gave up on it, and then the rapid evolution of desktop computers took away IBM's monopoly position. Whatever you think of Microsoft and IBM now, back then Microsoft did us all a service by helping yank the rug out from under IBM. (Microsoft now lives in fear that mobile computing and/or browser-based apps will do to Windows what Windows did to IBM mainframes.)
Market forces can allow a nimble start-up to take market away from an entrenched monopoly. But if that monopoly is cemented in place by laws, it's basically impossible for the start-ups to even get off the ground. Imagine if IBM had been able to get a law passed that payrolls could only be computed on a computer "certified" by a government agency, and the certification was a morass of red tape and fees. IBM would have just tasked a few of their full-time lawyers to navigating the red tape, would have coughed up a few fees they could easily afford, and would have relaxed knowing that no little uncertified desktop computers could undercut their monopoly.
And I'm not convinced that anti-trust laws are well-written or completely beneficial to the economy.
http://www.cato.org/publications/commentary/case-against-antitrust
do we really want to look like an idiot walking around with a giant brick to our head?
http://www.youtube.com/watch?v=WRLRjKCGHek
P.S. My favorite bit is at the very end of the video.
I agree 100%: if we are going to mutate the USB standard this much, let's take the opportunity to make a symmetric connector. I don't want to buy Apple products, but I do think that they did a great job on the physical design of the Lightning connector, and I wish I could have something like that on all my devices.
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
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.
Hey, diddle, diddle the overflow pdl To get a little more stack; If that's not enough then you lose it all And have to pop all the way back.