Do you honestly expect us to believe that somebody suddenly thought - "I know, I'll make an entirely new unnecessary distribution system for disk menus, we'll store them on a central server, and this will improve the user experience!"
Well, yes. I would have.
Consider: They aren't just menus. They're applications. Applications get patched, even on game consoles.
You don't "overlook a design mistake" this elaborate,
decision, and one not unique to DRM. If Ubuntu's servers are ever pwned, so are mine, because I fetch updates from Ubuntu.
The only reasonable goal here would be to remove ownership of the menus from the consumer, in order to restrict them to DRM-approved disks.
Unlikely. Again, speaking of my HD-DVD experience, but from what I remember, it was possible to DRM the menus, but not required. I suspect most of them were served unencrypted, over HTTP. It wouldn't be easy, but certainly possible, to hijack these and burn them to another disc.
It wouldn't even be particularly hard to intercept that traffic and serve up your own menus.
What's more, it would have been possible -- easier, in fact -- for them to include all that DRM, and not insist on checking for updates. Users wouldn't be able to MITM them and install custom menus, and you still wouldn't be able to rip the disc, through this system, anyway.
Menus do nothing to help DRM. DRM actually works better without menus. The only possible way this could be "defective by design" is if you count the fact that they're tracking when you play the movie.
reportedly it has something to do with them having removed support for middle-aged NVidia video cards.
I'm fairly sure that you can add that back in, as well. It's tricky, but you can coerce it to boot to a console (or just hit ctrl+alt+f1 once booted), then upgrade the drivers and restart X.
Or, if you just wanted to install, the Alternate CD should be fine.
Of course, I'm aware that at this point, you probably would be better off just picking a livecd that works with your video card, and includes a decent parted.
it's so messed up that FDISK won't touch it. I'll have to write zeros to the disk to make it usuable again.
Did you try gpart? I believe it's a tool to guess what the partition table used to look like. And you can always just zero out the MBR (the first 512 bytes), then try to guess what the partitions look like.
But then, maybe you were halfway through something like resizing a partition, making this very unlikely to work.
Didn't know they'd tied the "version number" to the year... it just says 8.something on the CD.
True, and you shouldn't have to. It's irrational, but it just bothers me when people call it "version 8".
Lots of companies make lots of money writing software in Java or using software written in this language.
Irrelevant. Lots of companies make money selling antivirus software.
For the same reason, they are also less safe, especially when the codebase becomes more complicated.
That's what we have unit tests for. And honestly, type checking is just a subset of unit testing.
What's more, it's a lot easier to implement static type checking on top of a more dynamic language than the other way around.
And I think you're underestimating just how much faster they are: If there's a crushing bug in a Perl script I banged out in ten minutes, I can just rewrite the entire thing (probably in Ruby this time) in another ten minutes. Problem solved.
Those 20 minutes is probably considerably less time than it would take for my first attempt in Java. I can spend the extra time writing tests (specs, really) -- and probably still have spent less time than that first attempt in Java, which is now considerably less safe. Can't be sure it does what you think it does until you test it.
Anyway, Java does allow you to dynamically modify your code, by using reflection
Which, unless it has changed, is pitifully limited, compared to Ruby's reflection. If nothing else, Ruby has eval.
Haven't bothered to compile that, but it's close enough for 4:30AM.
And you mentioned you know Perl. Hello World in Perl is one line of code -- two, if you count the shebang.
And while you did manage to complicate it further, it's never a good sign when "hello world" in a language requires so much infrastructure bullshit just to get started.
Trendy language snobs
I use Ruby on Rails at work, so I guess I qualify... but then, I've also played with Erlang recently, and I know enough Javascript to know it's a fundamentally better and more powerful language in all the ways I care about.
Don't get OO design
There's a quote somewhere that I'll have to find, from the person who actually coined the term "Object-oriented", who says that Java is absolutely not what he had in mind.
Of course, he was probably a bit more of a language snob, as he doesn't count Smalltalk, either. But Java is not the only OO language one could ask for.
Haven't seen benchmarks of Hotspot
I know Java is fast enough. I don't particularly care, for most projects, and Java is also living proof that if enough people like a language, they will eventually make it run fast. A more recent, clearer example is Javascript.
Has been legitimately burnt by one of the many serious bugs/design flaws
Can't speak to that, as I've successfully avoided it thoroughly enough that I haven't had a chance to. If I went back to it, I'd probably attempt to port some of the patterns I've learned elsewhere, and thus code around language flaws -- but I'd much rather code in a language that forces me to do that less. (No language is perfect, yet.)
Just don't like it (nothing wrong with that)
I really don't.
If memory footprint and load time aren't an issue and I need to go cross platform, Java is just my only option.
C/C++ are cross-platform, but it takes a recompile and a bit of awareness -- you need to choose cross-platform libraries.
Perl is cross-platform..NET has official and unofficial implementations on other platforms, though the official Windows version seems to be the only complete one.
Or they're a.NET/Ruby developer and are therefore sworn enemies to Java developers
Oh, I hated Java long before I learned Ruby.
My reasons range from objective, to subjective, to intangible. Perhaps the simplest: I believe software development is about expressing intent. The clearer we can express what we actually intend to do, not just the mechanism, the more elegant our code will be.
Java's syntax is relatively ugly. It makes it really difficult to write short, sweet code. And there isn't enough support for the kind of metaprogramming it would take to clean that syntax up.
Less code means it's more likely to express my intent, making it easier to understand, and it's also much easier to maintain and understand because of sheer (lack of) volume.
I also intensely dislike the explicit everything -- handling of exceptions really drove home for me just how insanely fucking verbose this language is, not to mention strict.
The simplest Hello World in Java that I know of, by heart:
class Hello {
public static void main(String [] args) {
System.out.println("Hello, world!");
} }
Oh, and don't forget, it has to be in a file called Hello.java, or it won't work.
as long as the hardware can be bricked by software, it remains an exploit that can be used by malicious software writers.
Except, where do you draw the line?
Software control of fans means a virus could spin them all down, and run some complex calculations (PI) to spin the CPU up.
Software control of hard drives means you can spin them up and down all day, and wear them out an order of magnitude faster.
Software control of a printer means you can print page after page of black ink, using up an ink cartridge.
Software control of a Roomba means you can deliberately crash it into walls, or possibly down the stairs.
I have enough coddling in my software. ("Are you sure you want to run this program from the Internet? It might be a virus!") While it might be safer, I really don't want to be in a situation where my hardware is telling me I can't do something, because I might screw it up.
I'm sorry -- justify it all you like. We all have bills to pay.
But to say this wasn't financially motivated is a baldfaced lie.
And to say it "isn't greed" is stupid, on top of that -- because the first time you say that, people will make the connection, and think "You know what? Those asshats really are greedy! I never thought of it that way before!"
While I haven't examined the disc itself, it seems incredibly unlikely that it's DRM.
I would lean towards something far simpler: A software update.
With HD-DVD, at least, there were rather huge differences between various players. National Geographic managed to put one out which wouldn't play on the Xbox 360.
And I don't really know of anyone, other than us (mostly me), who was trying to trim download sizes. For the most part, an update would mean downloading everything that wasn't audio or video -- so, all the menu graphics, all the scripts, and all the XML.
The smarter HD-DVDs pretty much just limited that damage to the "network" portion of the app, and left the menus used to actually view the movie untouched -- meaning, of course, that it'd be difficult or impossible to update those later, making it possible to have permanently broken discs (like that National Geographic one).
So, a very simple explanation would be: No, it didn't actually change the way anything looks. But maybe it fixed some critical bug.
Now, about the DRM...
I'm not even sure it's possible to change the DRM affecting a given (published) Blu-Ray disc -- after all, whatever they do, you still have the physical disc, which is still (as far as I know) entirely read-only.
No, the DRM is an entirely separate issue. Granted, it could lead to something like this -- but inferring that this update is only because of DRM, or that this failure is DRM-related, is a bit like confusing HDCP with HDMI.
(I intensely dislike HDCP, but it works on both DVI and HDMI. I am typing this on a monitor connected to my laptop through HDMI, which is, for me, just DVI without the thumbscrews. So there's no reason to use DVI over HDMI, unless you like thumbscrews.)
DRM is defective by design, and evil, and no amount of it is ever a good idea. But before you go off half-cocked, make sure what you're protesting is actually DRM-related, and not something completely orthogonal.
i thought the BD live content was extra content only downloaded once when you first play the disc--things like bonus scenes, soundtracks, ringtones, and other promo material--rather than just video streamed live each time you play it.
Neither, actually, unless they're being particularly stupid. More likely, downloaded once, whenever either you choose to download them, or the disc does -- and then saved, so you can watch them again. Live streaming would be reserved for places where it actually matters -- as in, content which is also being generated live.
preview trailers are something you skip over, not something you waste bandwidth on.
Preview trailers are also the most trivial, and the most useless, of the things that are possible with this.
I worked on some client-side programming for HD-DVD, before it died. Basically, you've got a little bit of local storage, an Internet connection, and a script engine. You can download small videos and play them, or you can run a program overlaid on top of the movie -- this is how menus were done, but we were doing a lot more than just menus.
Now, from what I remember of Paramount's discs, they pretty much re-downloaded several megs (at least) worth of data on boot -- including every single file needed for said scripts. The only exception was actual media, as in audio and video.
So, they're basically replacing a bunch of data that was already there on the disc. Unlike some other discs, you have no choice -- you will update, before you watch the movie.
That's not really "defectivebydesign", as it's got nothing to do with DRM. It is, however, a defective design. Subtle but very important difference.
It's possible none of this applies to the Blu-Ray, but I suspect it's very similar, and I very much doubt that any of it involves re-downloading the same trailer over and over.
As I understand it, in normal use, Git never forgets a commit. Is that really what you want for photos?
The other poster isn't entirely accurate -- I suspect Git does just fine with binary data. It's just that said binary data will stay in the tree forever.
It isn't a strange twist for them to be setting up a legit company for legit paid-for content either.
Given what they did to Revision3, which was a legit company distributing legit, free content, it seems like very much a strange twist.
Of course, if I get slightly more cynical, of course it makes sense -- good PR about them doing legit P2P, to counter bad PR about them attacking legit P2P. In fact, in light of this, the attack on Revision3 makes sense -- it would be an attack against a competitor.
This way, if I desperately need an extra 8GB of space, I can just `rm/swapfile`
Ah, so it's suspend-to-swapfile, not just suspend-to-file. Oh well.
I was kind of hoping for something cooler, like: Suspend process allocates exactly as big a file as it needs (and fails right there, coming back up, if that space isn't available), auto-stores the created file's current location, and hibernates. On resume, it simply rms the file.
But it seems like it's making a lot of assumptions. What about filesystems where there isn't necessarily a one-to-one relationship between a byte in a file and a byte on disk (compression, etc)? And that's to say nothing of FUSE...
I actually had (have?) an aggressive plan for refactoring the layer design between filesystems and volumes, and, as an emergent property, it solves this problem for the more interesting filesystems. But it's 3 AM, and I'm not in any state to do it justice -- nor will I have time for any ambitious hobby projects for probably a month.
Anyone's who's ever done anything like accidentally rsync 8 billion files [thank god for rsync 3] will know that having gads of swap available is a curse
Technically, in that case, the curse is rsync insisting on building the entire fscking file list ahead of time.
What I can't understand is why suspend doesn't seem to flush the file caches from memory when hibernating - writing 8GB of memory to swap, even when using compression, takes an utter age.
I imagine there's some way to configure it not just to drop all caches, but to drop a certain arbitrary percentage of them.
You see, when I first ran software suspend, it was pretty much what you describe -- and it sort of makes sense. Not saving caches means you hibernate faster, and it means the initial restore is faster. It also means that as soon as you restore, every single program that just woke up is going to have to pull its data off some random location of the disk, thrashing it to hell. That takes a lot longer than the entire boot process of just reading a bit more, but sequential.
First, if it's included, it's included as a program, not as part of the install.
That is: Boot it as a livecd (choose "Try Ubuntu without making any changes"), then don't click the big "install" link on the desktop. Instead, go looking for gparted. If it's not installed, you can actually install it to the livecd, the same way you'd install software on a running Ubuntu installation.
Regarding your earlier attempt: When you clicked "manual", you seem to be expecting something magical to happen:
neither repartitioned the disk (I tried both manual and automatic)
If you were wondering, "manual" means you have to do it. It should show you a partition table, and you then have to click on partitions and delete them, resize them, mark them to be formatted, set their target mountpoint, etc.
Finally, a nit: It's not "v8" per se. 8.04 is a date -- 04 (April) of 2008.
In fact, that's probably part of the reason why, at one point, glxgears required the commandline switch:
--I-acknowledge-that-this-is-not-a-benchmark
to enable the FPS display.
Now, I believe it's changed proportionately. You claim 3ghz gives you 500fps -- I just got over 8000 fps, and for years, multiple thousands has been the norm for me, when accelerated. So you can get a rough idea.
The point is, since you're not going to notice anything over 100fps -- realistically, anything over 60 -- there's no point in a video card letting you go that fast. I imagine a card could be built such that it would never run more than a few hundred FPS, but would render massive scenes at a comfortable 60 (vsync'd).
So, glxgears is still a decent diagnostic tool, as is Armagetron, Nexuiz, and others. It is not a proper benchmark, and absolutely should never be used in e-penis comparisons.
If there's a whoosh, I don't get it either, other than that it has to be...
I don't think Intel makes solid state drives. Nor does Intel make the EEE PC. Nor does any EEE PC ship with an experimental kernel. Nor does an ethernet card have anything to do with a hard drive.
Some quick Googling shows that the 901 may have gigabit, maybe not -- and if it did, and if they were this particular Intel card, you might be affected. Which would still have nothing to do with the SSD.
But after checking the manuals I could find, it doesn't look like it supports gigabit at all.
Granted, but is this really enough to do a full rewrite?
Suppose it was a Ruby On Rails project. Would you rewrite it in JSP just to get more developers? Would the number of developers make up for not only the massive amount of time to do the rewrite, but the extra time taken to maintain it and develop it further, once the rewrite was done?
If the target language wasn't Java, it would make slightly more sense. If the original implementation was really, really shoddy, it would make even more sense. (Think Myspace.)
I did not say "attempting to learn Java", I said "attempting Java".
As in, attempting to do anything useful in that language, in any reasonable amount of time. Especially when I've been spoiled with nice, modern, dynamic languages.
Seriously, have you seen Hello World in Java? Yes, I've gone beyond that, and yes, it did get better, but not by much.
Well, I haven't needed to do a BIOS upgrade in this millennium, I think
Good for you...
I know my keyboard has had its firmware upgraded at least once. I haven't had to do a BIOS update for awhile...
I do remember a series of incremental improvements to the whole process:
The very first time I flashed a BIOS, it was relatively easy -- just run the BIOS update program (in Windows), which formats a floppy for me, which I then boot off of. After booting the floppy, I still have to dump the BIOS, then load the new one -- from a DOS commandline.
I streamlined the process a bit when CDs got cheap -- I burned a FreeDOS CD, and left the actual updates on the hard drive, so I could keep using the same CD.
And some BIOSes supported flashing themselves, from inside the BIOS. Unfortunately, these tools were mostly limited to floppies -- I had to go pick up a floppy drive and plug it into the computer.
More recently -- it turned out I didn't actually need an update, but it was such an easy process that I didn't mind. Pretty much just paste a couple of commands into a terminal on Linux (versus printing them, writing, memorizing, or copying from another computer), then on my next reboot, new BIOS.
Easiest, of course, was on OS X -- firmware updates of any kind are included with Apple's "Software Update", meaning you might not even notice.
flashing the EEPROM on a NIC should be a rare event.
So should any kind of BIOS update.
But then, so should any software bug. You could say that firmware should be held to a higher standard, and I'd agree, but if and when there's a firmware bug, I'd much rather have it patched quickly and conveniently than have to schedule a few hours (or an afternoon), and dig up an old floppy drive and/or a copy of FreeDOS.
Unlikely. I would imagine that this flavor involves writing the new firmware to some dedicated chunk of memory, where it will be pulled either by the OS or the BIOS itself on next reboot.
Linus has a very good analogy here -- in fact, I love the fact that on the rare occasions I have to set modelines myself, I can pretty much put whatever I want, knowing that if it doesn't work, I can just ctrl+alt+backspace and try again.
But the conclusion does bother me: We're basically saying that all software is buggy, or that we're incapable of preventing this kind of thing from happening (in software). This is true of most modern OS designs -- monolithic kernels do make it possible for pretty much any driver to accidentally ruin any other driver's day.
The proposed workaround, then, is to prevent that memory from being written -- and to prevent this in hardware, for no other reason than to avoid having to write it into every kernel that might potentially allow buggy code to run in Ring 0.
I don't like either solution. Hardware shouldn't be brickable from software, or at least, not so easily. But software shouldn't need hardware to coddle it, either -- why is the SSD in this laptop emulating a hard disk?
Slashdot Mirror
Do you honestly expect us to believe that somebody suddenly thought - "I know, I'll make an entirely new unnecessary distribution system for disk menus, we'll store them on a central server, and this will improve the user experience!"
Well, yes. I would have.
Consider: They aren't just menus. They're applications. Applications get patched, even on game consoles.
You don't "overlook a design mistake" this elaborate,
decision, and one not unique to DRM. If Ubuntu's servers are ever pwned, so are mine, because I fetch updates from Ubuntu.
The only reasonable goal here would be to remove ownership of the menus from the consumer, in order to restrict them to DRM-approved disks.
Unlikely. Again, speaking of my HD-DVD experience, but from what I remember, it was possible to DRM the menus, but not required. I suspect most of them were served unencrypted, over HTTP. It wouldn't be easy, but certainly possible, to hijack these and burn them to another disc.
It wouldn't even be particularly hard to intercept that traffic and serve up your own menus.
What's more, it would have been possible -- easier, in fact -- for them to include all that DRM, and not insist on checking for updates. Users wouldn't be able to MITM them and install custom menus, and you still wouldn't be able to rip the disc, through this system, anyway.
Menus do nothing to help DRM. DRM actually works better without menus. The only possible way this could be "defective by design" is if you count the fact that they're tracking when you play the movie.
I would imagine most of the blame here rests with Flash, and not with Javascript.
reportedly it has something to do with them having removed support for middle-aged NVidia video cards.
I'm fairly sure that you can add that back in, as well. It's tricky, but you can coerce it to boot to a console (or just hit ctrl+alt+f1 once booted), then upgrade the drivers and restart X.
Or, if you just wanted to install, the Alternate CD should be fine.
Of course, I'm aware that at this point, you probably would be better off just picking a livecd that works with your video card, and includes a decent parted.
it's so messed up that FDISK won't touch it. I'll have to write zeros to the disk to make it usuable again.
Did you try gpart? I believe it's a tool to guess what the partition table used to look like. And you can always just zero out the MBR (the first 512 bytes), then try to guess what the partitions look like.
But then, maybe you were halfway through something like resizing a partition, making this very unlikely to work.
Didn't know they'd tied the "version number" to the year... it just says 8.something on the CD.
True, and you shouldn't have to. It's irrational, but it just bothers me when people call it "version 8".
Lots of companies make lots of money writing software in Java or using software written in this language.
Irrelevant. Lots of companies make money selling antivirus software.
For the same reason, they are also less safe, especially when the codebase becomes more complicated.
That's what we have unit tests for. And honestly, type checking is just a subset of unit testing.
What's more, it's a lot easier to implement static type checking on top of a more dynamic language than the other way around.
And I think you're underestimating just how much faster they are: If there's a crushing bug in a Perl script I banged out in ten minutes, I can just rewrite the entire thing (probably in Ruby this time) in another ten minutes. Problem solved.
Those 20 minutes is probably considerably less time than it would take for my first attempt in Java. I can spend the extra time writing tests (specs, really) -- and probably still have spent less time than that first attempt in Java, which is now considerably less safe. Can't be sure it does what you think it does until you test it.
Anyway, Java does allow you to dynamically modify your code, by using reflection
Which, unless it has changed, is pitifully limited, compared to Ruby's reflection. If nothing else, Ruby has eval.
Haven't bothered to compile that, but it's close enough for 4:30AM.
And you mentioned you know Perl. Hello World in Perl is one line of code -- two, if you count the shebang.
And while you did manage to complicate it further, it's never a good sign when "hello world" in a language requires so much infrastructure bullshit just to get started.
Trendy language snobs
I use Ruby on Rails at work, so I guess I qualify... but then, I've also played with Erlang recently, and I know enough Javascript to know it's a fundamentally better and more powerful language in all the ways I care about.
Don't get OO design
There's a quote somewhere that I'll have to find, from the person who actually coined the term "Object-oriented", who says that Java is absolutely not what he had in mind.
Of course, he was probably a bit more of a language snob, as he doesn't count Smalltalk, either. But Java is not the only OO language one could ask for.
Haven't seen benchmarks of Hotspot
I know Java is fast enough. I don't particularly care, for most projects, and Java is also living proof that if enough people like a language, they will eventually make it run fast. A more recent, clearer example is Javascript.
Has been legitimately burnt by one of the many serious bugs/design flaws
Can't speak to that, as I've successfully avoided it thoroughly enough that I haven't had a chance to. If I went back to it, I'd probably attempt to port some of the patterns I've learned elsewhere, and thus code around language flaws -- but I'd much rather code in a language that forces me to do that less. (No language is perfect, yet.)
Just don't like it (nothing wrong with that)
I really don't.
If memory footprint and load time aren't an issue and I need to go cross platform, Java is just my only option.
C/C++ are cross-platform, but it takes a recompile and a bit of awareness -- you need to choose cross-platform libraries.
Perl is cross-platform. .NET has official and unofficial implementations on other platforms, though the official Windows version seems to be the only complete one.
Or they're a .NET/Ruby developer and are therefore sworn enemies to Java developers
Oh, I hated Java long before I learned Ruby.
My reasons range from objective, to subjective, to intangible. Perhaps the simplest: I believe software development is about expressing intent. The clearer we can express what we actually intend to do, not just the mechanism, the more elegant our code will be.
Java's syntax is relatively ugly. It makes it really difficult to write short, sweet code. And there isn't enough support for the kind of metaprogramming it would take to clean that syntax up.
Less code means it's more likely to express my intent, making it easier to understand, and it's also much easier to maintain and understand because of sheer (lack of) volume.
I also intensely dislike the explicit everything -- handling of exceptions really drove home for me just how insanely fucking verbose this language is, not to mention strict.
The simplest Hello World in Java that I know of, by heart:
Oh, and don't forget, it has to be in a file called Hello.java, or it won't work.
Contrast this to Perl:
Or Python:
Or Ruby:
as long as the hardware can be bricked by software, it remains an exploit that can be used by malicious software writers.
Except, where do you draw the line?
Software control of fans means a virus could spin them all down, and run some complex calculations (PI) to spin the CPU up.
Software control of hard drives means you can spin them up and down all day, and wear them out an order of magnitude faster.
Software control of a printer means you can print page after page of black ink, using up an ink cartridge.
Software control of a Roomba means you can deliberately crash it into walls, or possibly down the stairs.
I have enough coddling in my software. ("Are you sure you want to run this program from the Internet? It might be a virus!") While it might be safer, I really don't want to be in a situation where my hardware is telling me I can't do something, because I might screw it up.
I'm sorry -- justify it all you like. We all have bills to pay.
But to say this wasn't financially motivated is a baldfaced lie.
And to say it "isn't greed" is stupid, on top of that -- because the first time you say that, people will make the connection, and think "You know what? Those asshats really are greedy! I never thought of it that way before!"
While I haven't examined the disc itself, it seems incredibly unlikely that it's DRM.
I would lean towards something far simpler: A software update.
With HD-DVD, at least, there were rather huge differences between various players. National Geographic managed to put one out which wouldn't play on the Xbox 360.
And I don't really know of anyone, other than us (mostly me), who was trying to trim download sizes. For the most part, an update would mean downloading everything that wasn't audio or video -- so, all the menu graphics, all the scripts, and all the XML.
The smarter HD-DVDs pretty much just limited that damage to the "network" portion of the app, and left the menus used to actually view the movie untouched -- meaning, of course, that it'd be difficult or impossible to update those later, making it possible to have permanently broken discs (like that National Geographic one).
So, a very simple explanation would be: No, it didn't actually change the way anything looks. But maybe it fixed some critical bug.
Now, about the DRM...
I'm not even sure it's possible to change the DRM affecting a given (published) Blu-Ray disc -- after all, whatever they do, you still have the physical disc, which is still (as far as I know) entirely read-only.
No, the DRM is an entirely separate issue. Granted, it could lead to something like this -- but inferring that this update is only because of DRM, or that this failure is DRM-related, is a bit like confusing HDCP with HDMI.
(I intensely dislike HDCP, but it works on both DVI and HDMI. I am typing this on a monitor connected to my laptop through HDMI, which is, for me, just DVI without the thumbscrews. So there's no reason to use DVI over HDMI, unless you like thumbscrews.)
DRM is defective by design, and evil, and no amount of it is ever a good idea. But before you go off half-cocked, make sure what you're protesting is actually DRM-related, and not something completely orthogonal.
i thought the BD live content was extra content only downloaded once when you first play the disc--things like bonus scenes, soundtracks, ringtones, and other promo material--rather than just video streamed live each time you play it.
Neither, actually, unless they're being particularly stupid. More likely, downloaded once, whenever either you choose to download them, or the disc does -- and then saved, so you can watch them again. Live streaming would be reserved for places where it actually matters -- as in, content which is also being generated live.
preview trailers are something you skip over, not something you waste bandwidth on.
Preview trailers are also the most trivial, and the most useless, of the things that are possible with this.
I worked on some client-side programming for HD-DVD, before it died. Basically, you've got a little bit of local storage, an Internet connection, and a script engine. You can download small videos and play them, or you can run a program overlaid on top of the movie -- this is how menus were done, but we were doing a lot more than just menus.
Now, from what I remember of Paramount's discs, they pretty much re-downloaded several megs (at least) worth of data on boot -- including every single file needed for said scripts. The only exception was actual media, as in audio and video.
So, they're basically replacing a bunch of data that was already there on the disc. Unlike some other discs, you have no choice -- you will update, before you watch the movie.
That's not really "defectivebydesign", as it's got nothing to do with DRM. It is, however, a defective design. Subtle but very important difference.
It's possible none of this applies to the Blu-Ray, but I suspect it's very similar, and I very much doubt that any of it involves re-downloading the same trailer over and over.
As I understand it, in normal use, Git never forgets a commit. Is that really what you want for photos?
The other poster isn't entirely accurate -- I suspect Git does just fine with binary data. It's just that said binary data will stay in the tree forever.
It isn't a strange twist for them to be setting up a legit company for legit paid-for content either.
Given what they did to Revision3, which was a legit company distributing legit, free content, it seems like very much a strange twist.
Of course, if I get slightly more cynical, of course it makes sense -- good PR about them doing legit P2P, to counter bad PR about them attacking legit P2P. In fact, in light of this, the attack on Revision3 makes sense -- it would be an attack against a competitor.
The fact that there's anything to open source suggests that it's not entirely hardware.
Is your claim that Roku's software is more efficient than a Mythfrontend? If not, why didn't they, in building their $99 hardware device, use Myth?
And MythTV can be useful, as a frontend, without a hard disk.
http://mysettopbox.tv/knoppmyth.html
If it could not, I ask again, would it have been so much harder to build a diskless mythfrontend than to write something completely from scratch?
This way, if I desperately need an extra 8GB of space, I can just `rm /swapfile`
Ah, so it's suspend-to-swapfile, not just suspend-to-file. Oh well.
I was kind of hoping for something cooler, like: Suspend process allocates exactly as big a file as it needs (and fails right there, coming back up, if that space isn't available), auto-stores the created file's current location, and hibernates. On resume, it simply rms the file.
But it seems like it's making a lot of assumptions. What about filesystems where there isn't necessarily a one-to-one relationship between a byte in a file and a byte on disk (compression, etc)? And that's to say nothing of FUSE...
I actually had (have?) an aggressive plan for refactoring the layer design between filesystems and volumes, and, as an emergent property, it solves this problem for the more interesting filesystems. But it's 3 AM, and I'm not in any state to do it justice -- nor will I have time for any ambitious hobby projects for probably a month.
Anyone's who's ever done anything like accidentally rsync 8 billion files [thank god for rsync 3] will know that having gads of swap available is a curse
Technically, in that case, the curse is rsync insisting on building the entire fscking file list ahead of time.
What I can't understand is why suspend doesn't seem to flush the file caches from memory when hibernating - writing 8GB of memory to swap, even when using compression, takes an utter age.
I imagine there's some way to configure it not just to drop all caches, but to drop a certain arbitrary percentage of them.
You see, when I first ran software suspend, it was pretty much what you describe -- and it sort of makes sense. Not saving caches means you hibernate faster, and it means the initial restore is faster. It also means that as soon as you restore, every single program that just woke up is going to have to pull its data off some random location of the disk, thrashing it to hell. That takes a lot longer than the entire boot process of just reading a bit more, but sequential.
First, if it's included, it's included as a program, not as part of the install.
That is: Boot it as a livecd (choose "Try Ubuntu without making any changes"), then don't click the big "install" link on the desktop. Instead, go looking for gparted. If it's not installed, you can actually install it to the livecd, the same way you'd install software on a running Ubuntu installation.
Regarding your earlier attempt: When you clicked "manual", you seem to be expecting something magical to happen:
neither repartitioned the disk (I tried both manual and automatic)
If you were wondering, "manual" means you have to do it. It should show you a partition table, and you then have to click on partitions and delete them, resize them, mark them to be formatted, set their target mountpoint, etc.
Finally, a nit: It's not "v8" per se. 8.04 is a date -- 04 (April) of 2008.
First, this does nothing to clean out my inbox. If I were to paste The Form, the first thing I'd check is "Armies of worm-ridden Windows boxen".
And what do you do about blind users?
Pointless, though -- it's still vulnerable to the Mechanical Turk / free porn site attack.
In fact, that's probably part of the reason why, at one point, glxgears required the commandline switch:
--I-acknowledge-that-this-is-not-a-benchmark
to enable the FPS display.
Now, I believe it's changed proportionately. You claim 3ghz gives you 500fps -- I just got over 8000 fps, and for years, multiple thousands has been the norm for me, when accelerated. So you can get a rough idea.
The point is, since you're not going to notice anything over 100fps -- realistically, anything over 60 -- there's no point in a video card letting you go that fast. I imagine a card could be built such that it would never run more than a few hundred FPS, but would render massive scenes at a comfortable 60 (vsync'd).
So, glxgears is still a decent diagnostic tool, as is Armagetron, Nexuiz, and others. It is not a proper benchmark, and absolutely should never be used in e-penis comparisons.
Psst: 8212.271 FPS.
If there's a whoosh, I don't get it either, other than that it has to be...
I don't think Intel makes solid state drives. Nor does Intel make the EEE PC. Nor does any EEE PC ship with an experimental kernel. Nor does an ethernet card have anything to do with a hard drive.
Some quick Googling shows that the 901 may have gigabit, maybe not -- and if it did, and if they were this particular Intel card, you might be affected. Which would still have nothing to do with the SSD.
But after checking the manuals I could find, it doesn't look like it supports gigabit at all.
Granted, but is this really enough to do a full rewrite?
Suppose it was a Ruby On Rails project. Would you rewrite it in JSP just to get more developers? Would the number of developers make up for not only the massive amount of time to do the rewrite, but the extra time taken to maintain it and develop it further, once the rewrite was done?
If the target language wasn't Java, it would make slightly more sense. If the original implementation was really, really shoddy, it would make even more sense. (Think Myspace.)
I did not say "attempting to learn Java", I said "attempting Java".
As in, attempting to do anything useful in that language, in any reasonable amount of time. Especially when I've been spoiled with nice, modern, dynamic languages.
Seriously, have you seen Hello World in Java? Yes, I've gone beyond that, and yes, it did get better, but not by much.
Well, I haven't needed to do a BIOS upgrade in this millennium, I think
Good for you...
I know my keyboard has had its firmware upgraded at least once. I haven't had to do a BIOS update for awhile...
I do remember a series of incremental improvements to the whole process:
The very first time I flashed a BIOS, it was relatively easy -- just run the BIOS update program (in Windows), which formats a floppy for me, which I then boot off of. After booting the floppy, I still have to dump the BIOS, then load the new one -- from a DOS commandline.
I streamlined the process a bit when CDs got cheap -- I burned a FreeDOS CD, and left the actual updates on the hard drive, so I could keep using the same CD.
And some BIOSes supported flashing themselves, from inside the BIOS. Unfortunately, these tools were mostly limited to floppies -- I had to go pick up a floppy drive and plug it into the computer.
More recently -- it turned out I didn't actually need an update, but it was such an easy process that I didn't mind. Pretty much just paste a couple of commands into a terminal on Linux (versus printing them, writing, memorizing, or copying from another computer), then on my next reboot, new BIOS.
Easiest, of course, was on OS X -- firmware updates of any kind are included with Apple's "Software Update", meaning you might not even notice.
flashing the EEPROM on a NIC should be a rare event.
So should any kind of BIOS update.
But then, so should any software bug. You could say that firmware should be held to a higher standard, and I'd agree, but if and when there's a firmware bug, I'd much rather have it patched quickly and conveniently than have to schedule a few hours (or an afternoon), and dig up an old floppy drive and/or a copy of FreeDOS.
possibly not even a reboot
Unlikely. I would imagine that this flavor involves writing the new firmware to some dedicated chunk of memory, where it will be pulled either by the OS or the BIOS itself on next reboot.
Linus has a very good analogy here -- in fact, I love the fact that on the rare occasions I have to set modelines myself, I can pretty much put whatever I want, knowing that if it doesn't work, I can just ctrl+alt+backspace and try again.
But the conclusion does bother me: We're basically saying that all software is buggy, or that we're incapable of preventing this kind of thing from happening (in software). This is true of most modern OS designs -- monolithic kernels do make it possible for pretty much any driver to accidentally ruin any other driver's day.
The proposed workaround, then, is to prevent that memory from being written -- and to prevent this in hardware, for no other reason than to avoid having to write it into every kernel that might potentially allow buggy code to run in Ring 0.
I don't like either solution. Hardware shouldn't be brickable from software, or at least, not so easily. But software shouldn't need hardware to coddle it, either -- why is the SSD in this laptop emulating a hard disk?
I mean, who in their right mind would call a PC without an operating system bricked?
Entirely too many people. Of course, "right mind" is subjective...
Except for the part where they're doing a language swap at all.
Why?