Interesting. I haven't tried that here -- I do have a virtualized Windows, but it's different enough hardware that I had to call Microsoft to register the bare-metal install after first installing on the VM.
I could also download and then backup during the day in my VM, then restore the backup.
For now, I just suck it up and enjoy my fiber -- only took an hour to download Episode 2 anyway. It is, however, an irritation.
Bad idea, a huge cache is actually less efficient than just grabbing the data from the source in many instances.
In enough others, it's much more efficient. And I'm not just talking about the Web.
Imagine you have 10M items in your disk cache,
I'm on a rather small filesystem -- 365,934 files. This is a laptop -- I tend not to keep more on it than I have to.
It also takes 9 ms to list a directory. That's a listing, not a single file lookup. It's also small enough to be unreliable -- repeating the experiment gives different results.
Now, I haven't tried this lately, but are you telling me that a filesystem with 10 million records would respond slower? Even if you're right, that lookup was still fast enough that it hardly matters -- but I don't think you are. I think an index could be designed to be fast enough.
trying to find a 1x1 pix graphic
There is no good reason to have a 1x1 pixel graphic. Certainly not in a webpage.
in the index of 10M items is going to take MUCH longer than just downloading that file in the HTTP 1.1 stream.
That's a pathological case. I'm also going to guess that it's not enough longer to care about -- especially considering the overall gain in the vast majority of cases, where it's not a 1x1 pixel image.
For example: I know people with capped Internet. Not Comcast-capped, 250-megs-per-day capped. I am sure they would love if YouTube videos were cached for them -- every megabyte helps. It's not like they were doing anything with the other 50 or 100 gigs.
Few people are going to let you install some random driver on their notebook just to access your USB drive.
Oddly, most people I know are going to let me install anything I want. They'll be curious what it is, but they won't actually stop me -- they assume I know what I'm doing.
What's more, most people aren't going to have autorun disabled -- therefore, as soon as I plug in, there's a chance I'm running something anyway.
It's in Ubuntu but what about Debian or CentOS or Sabayon (this being three distros I encountered lately on random computers)?
If someone's running Sabayon, either they have a very good rationale for not having ntfs-3g installed, or they'll thank you for showing them how to get it working.
And a Linux user should have even less of a problem, since these packages are most likely available via a trusted repository -- so they don't have to trust anything from my disk.
The reason we put up with FAT32 is not high compatibility, it's absolute compatibility. You can stick a FAT32-formatted USB drive into any random comouter you encounter and it will definitely mount with no kind of setup neccessary.
So long as it's at least Windows 2000. 98 won't do it.
You're right, of course, but it still seems incredibly stupid that we're using a DOS filesystem because nobody had the presence of mind to distribute something useful with the first USB mass storage drivers.
We've got FAT32 for thumb drives, NTFS for Windows hard drives, HFS+ for OS X hard drives, and ISO9660 and UDF for CDs/DVDs -- several versions of them, in fact, with Rock Ridge extensions, Joliet extensions, plus UDF2...
Now, most distros do stick to the standard pattern of one swap partition and one big root partition, formatted as ext3.
However, just like the rest of the world, we recognize that different situations call for different filesystems. UbiFS is a filesystem sitting directly on flash media (instead of above some wear-leveling ATA-emulating layer designed for FAT). sshfs is a (fuse-based) filesystem for accessing remote filesystems via ssh. Squashfs is a read-only, heavily-compressed filesystem, ideal for use on livecds and DVDs. And then there are the journaling filesystems like ext3.
It would be stupid beyond belief to suggest that we should unify those things into one giant, lumbering, monolithic, bloated filesystem.
Instead of one stable implementation you have this whole business of a dozen half-assed implementations again.
Look at the above filesystems I've mentioned. What is half-assed about them? Please be specific.
If Linux coders were designing "standards", we'd have TCP/IP, TCP/IP2, TCP/IP3, TCP/IP4-beta5-pre46 and what not.
Actually, I'm betting quite a lot of Linux coders were designing them -- and the situation isn't far from what you describe.
We still have ipv4 and ipv6. We also have TCP, UDP, and ICMP. We have implementations of TCP over UDP. We have older protocols like AppleTalk and IPX -- dead in most places, but there's a reason Linux still supports them. We have NetBIOS and DNS. We have Zeroconf and Bonjour.
This right there shows you what's wrong with Linux.
Really?
No, filesystems are actually one place Linux is king -- with the possible exception of ZFS, but that's being rectified. We support just about everyone else's filesystems -- from 9pfs to sysvfs, and everything in between. With FUSE, we even support a few filesystems that won't go into the kernel, for technical or legal reasons.
In fact, it speaks quite loudly about the quality of desktop Linux that you think this is what's wrong with Linux. You could have chosen to complain about how slow suspend/resume is on some devices. You could have raged about the lack of support for some obscure wireless card, or whined about being forced to modify your kernel commandline for your touchpad to work.
These might all be valid complaints, but you didn't raise them. Instead, you chose to complain about how many filesystems we have -- how dare we provide so much choice!
And seriously, what kind of fucking ridiculous name is Tux3?!
The same kind of fucking ridiculous name that FAT32 is. Or maybe you like HFS Plus?
Actually, if you want a filesystem usable by everyone it will definitely have to come from Microsoft.
It doesn't much matter whether they cooperate. Even if they insist that the Windows boot device continue to be NTFS, there's a standard way to write filesystem drivers for Windows (ext2 is already supported), and it's easy to put just about everything except Windows itself on another partition, if we have to. (Which we probably won't -- we could even slipstream it in.)
So, we can force the issue.
And suppose I have a portable hard drive, which I want to make sure is readable everywhere -- all I have to do is make a separate FAT32 partition with all the relevant software on it for Windows and OS X to read the other partition.
ntfs-3g is hardly a default package in most distros so no dice.
On Macs, it's supported via MacFUSE, which users still need to install. On Ubuntu, it absolutely is a default package, already there even on the livecd.
I've repeatedly proposed something, only to find that ZFS already implements it: Define one layer which is solely responsible for storing your bare primitives, like a sequence of data. It is the FS-level equivalent of malloc/free.
Then, implement everything else on top of that layer. Databases could sit directly on the layer -- no reason they need to pretend to create files. Filesystems would sit on that layer, implementing structures like directories and POSIX file permissions.
Of course, while I'm at it, I have this other idea -- unify disk caches. It should be possible for me to allocate my entire available free space as a shared cache, between my package manager, browser, everything -- then, provide a common mechanism for reclaiming that space when something wants disk space.
True. However, a true native port would very likely include the existing x64 support. And no, I don't really get that advantage, as a single 32-bit process (on Windows) is limited to, what, 2 gigs of RAM? The only advantage would be if I needed the other 2 gigs for something else, rather than 1.5 gigs.
I still would also gain the benefit of being able to download while I work, having a supported solution, not having to reboot, being able to instantly join a game from an IM, and so on.
It does, however, require some variant of Flash -- I applaud efforts like Gnash, but ultimately, it's exactly as much a "solution" to Flash as Wine is a solution to a lack of native apps.
It means that ultimately, I have to use the real Adobe Flash, because some things will require it. About the only way that will change is if Adobe either releases the Flash source, or starts heavily supporting one of the free alternatives.
I can almost rationalize away making Susan Calvin a love interest
Having not seen the movie, I can say I probably wouldn't mind. Even when Asimov did sex, it was pretty dry -- he didn't write characters well at all, he wrote ideas. My favorite book of his was Bicentennial Man, which was co-authored with someone who knew emotion.
2001 would certainly be a failure, but not for the reasons you imagine.
It was, in fact, so crammed with special effects -- effects which would be boringly easy to do today -- that when you get over that, it's boring.
Not "boring" as in "no explosions", but "boring" as in "Let's waste several minutes of our lives watching these two objects in space get closer and closer together, and finally dock."
My theory is that, well, the movie was released in the late 60's -- 1968, one year before the Summer of Love. So, when it was released, it was an amazing movie, mostly because so many moviegoers were stoned out of their minds.
I don't disagree with your point -- I don't usually mind a movie that's simple, yet crammed with special effects. But I much prefer a movie that makes me think. And there are too few of those, scifi or not.
Because it's actually more painful to run it in Windows, for some of us. Here, let me count the ways:
Linux has pretty good 64-bit support. The last remaining broken piece was browser plugins -- Java has been ported, and Flash will be soon. Windows 64-bit sucks before Vista, and Vista sucks in so many other ways that 64-bit is hardly a concern.
And yes, Valve games can use 64-bit and multicore. And I do have 4 gigs of RAM, which means XP can only see 3.5 gigs.
I also run Linux for everything other than games. That means, not only is there the irritation of having to reboot -- somewhat mitigated, as I can hibernate one and boot another -- but that I have to maintain Windows, which is much more work for me than maintaining Linux -- on top of which, I still have to maintain Linux. (Example: Ever try to hunt down XP drivers for a made-for-Vista laptop?)
Steam also insists that I install/update games via its client. That's great, if I'm running Windows anyway -- and I'm on fiber, so it's fast. But it means I can't download while on Linux. What's more, I can't play a Steam game I've already got while I wait -- as soon as Steam sees me playing a game, it kills all downloads. I suppose it's to keep me from lagging -- thanks, but it reacts the same way if I'm playing a single-player game.
If there was a Linux client, I'd just leave it running and not care.
And then there's the fact that Steam itself is a good deal more than just a game client, now -- assuming they've finally gotten the Friends feature working, it's also an IM client. That would be nice -- a friend IMs me, inviting me to a game, and rather than rebooting, I just click "yes" in that window -- and he can IM me from the game, he doesn't have to alt+tab to some other client to a Pidgin-friendly service.
Now, granted, I could run games under Wine. I do, for some games -- MMOs, I pretty much demand that they run windowed on Linux, because I absolutely do multitask with those. But with Steam, there's a performance hit (all Valve games are DirectX only, now), there's again 32-bit only (no Win64 support in Wine yet), and none of it is supported, meaning if I have any problems, I'm on my own.
Still, it's not as though there would be no benefit. Even if these end up being winelib'd apps, at least they're supported, and it's a step in the right direction -- next up would likely be an OpenGL port. It also means that some of the non-Valve games on Steam which have native Linux clients would also work in Steam.
If the device manufacturers had put the firmware in ROM (flash/EEPROM/whatever) attached to the peripheral rather than downloaded by the driver, does that really change anything?
If the license forbids you from distributing the binary blob in the driver, it changes quite a lot.
my hope is that the Ubuntu/Fedora will not change their approach.
I don't care much. I never used Ubuntu with any illusions that it would be 100% "free software" -- despite my best efforts to the contrary, I occasionally have to communicate with people via Skype. Despite the HTML5 effort, YouTube still requires Flash. And no matter what my ideology, if I'm a gamer, I'm going to be using proprietary software.
But it is nice to keep the definition clear. I have no problem with proprietary software, but let's not pretend it's something else.
I would rather have a solid card with a binary blob than a "free" card that stinks.
Nvidia is, unfortunately, an example of a solid card with a binary blob that stinks.
Go ahead and piss of companies that supported Linux for years.
By doing what?
I'm sorry, I never called nVidia "evil", or anything of the sort. Certainly, I'm grateful that I'm able to buy pretty much any nVidia card and have a better chance of finding working drivers for Linux than for Windows.
(True story: This laptop shipped with Ubuntu. Yet the only drivers available from the Dell website were for Vista, and nvidia claimed that Dell are the only ones allowed to distribute an XP driver. So I actually had to get a tech to give me a download link. On Ubuntu, it Just Worked, even when I reinstalled 64-bit...)
However, I'm not doing them any favors by pretending they have good drivers. They don't. Intel frequently beats them for 2D performance, and for things like Compiz and KDE4 -- which is sad, when you consider how weak the current Intel cards are. And I've had more than a few nvidia-driver crashes on an otherwise-functioning system.
Were the driver open, these problems might still exist, but at least I'd have a chance of solving them. As it is, the only thing I can do is idly threaten to go ATI next time.
All of which is customer feedback, which is something many companies devote a lot of time and effort into collecting. If that "pisses them off", then they deserve to die.
Is it any more free than having a distro that's free but not having the freedom to run it on your hardware because it's completely useless?
Having a distro like that serves at least one practical purpose: I can use it to evaluate a given set of hardware for compatibility. That can inform future purchasing decisions.
For instance, having used Linux, I now know that I will never knowingly buy a Broadcom wireless card -- or, very likely, anything from Broadcom -- even for devices I don't plan to run Linux on.
This is just taking that one step further.
it's not like I could buy a complete set of open hardware
Actually, under certain, limited circumstances, you can. I believe the OpenMoko Freerunner was such a device.
I'm talking about the whole process -- which, for me, is:
- Boot livecd
- Backup everything
- Reformat
Then, there's the pre-emptive steps:
- Boot livecd (or other OS)
- Take disk image of software partition (with ntfsclone)
- Before any major change, restore that image, make the change, then save a new one
Combined with the fact that I don't use Windows very much, malware is pretty much a non-issue for me. I don't even have any kind of anti-malware beyond the standard Windows firewall.
I was deliberately testing only reads. If I was to test writes, it would probably be if=/dev/zero, of=whatever. But that would allow filesystem buffering to become more of a factor...
A quick test shows somewhat less than 60 megs/sec. But then, I don't really need writes to be as fast, simply because I'm almost never writing that much.
Surely you jest. I use Gmail every day, and it's lightning fast on pretty much any connection. About as fast as I could ask for with the keyboard shortcuts.
they all suffer from the most bizarre and twisted coding problems I have ever seen.
Be specific.
CSS is STILL fundamentally broken and behaves erratically as evidenced by the box model, which you cannot to behave correctly browser to browser platform to platform.
Are you going to tell me that a native app has it any easier with cross-platform compatibility?
If you're going to talk about a library, that's fine -- consider that there are plenty of libraries out there for javascript-as-a-client which make the CSS issue mostly go away.
DOM still has really niggling and dumb problems after all these years as well.
Like what? Any which aren't already abstracted away by things like jQuery?
In the final analysis what we all want is a set of tools that will allow us to design a screen with a particular look and feel that will be presented exactly the same no matter where it is displayed.
Incorrect.
What I want is a set of tools that will allow me to design a screen with an independent look and feel, that will be presented exactly the way the user wants it to be.
If I use ctrl+mousewheel to change the font size, your app should be able to handle it. That's actually a feature that's sorely missing from a lot of desktop applications.
Today you have to combine three very different styles of design and coding, they are HTML, CSS and Java Script to come up with anything that is remotely useful for doing anything more then displaying text.
It's called a domain-specific language. On the server, you most likely have to combine some form of SQL with your application, and when things go wrong, you'll want to be able to understand HTTP.
HTML, Javascript, and CSS all do fundamentally different things.
HTML is a markup language -- it does markup much better than Javascript does (with the DOM). Well enough, in fact, that at least a couple GUI toolkits allow you to use some HTML-like syntax for rich text.
We need to glue all those together in a coherent manner that brings it to a true object model.
You're making another large assumption -- that Object-Oriented Programming is the be-all and end-all of methodologies.
To change the background I have to use Java Script to interrogate DOM to get to the right CSS selector and change that and my god what a pain that is!
That's why we have jQuery.
Would it not be simpler to just do this?
ImgBox = Box.New([styleReference]);
What's Box, and where does it get defined? How about styleReference -- how does that get defined? And how do I then take my ImgBox and insert it into the document? How do I assign all of the children of the old box to this new one?
If styleReference was defined in CSS, then we have something that does what you want already. It's just as simple, but unlike your example, it actually works, and does cover all of the above:
$('#my_div').removeClass('foo').addClass('bar');
Further all since java scipt is loaded when the page is loaded it should be trivial to have static events pre-built for each component
Depending what you mean by "OnExit", this does, in fact, exist already. Slightly different names and syntax, but the idea is the same.
would it not follow that that the following call would be far more appropriate then what we do now?
most scripting languages discourage abstraction because they aren't set up to enforce OOP concepts.
Wait, what? It's not possible to encourage something without enforcing it?
Javascript doesn't force anything, and yes, you can create BASIC-like spaghetti. But a bad programmer can create BASIC-like spaghetti in any language. A good programmer will take the time to learn Javascript's prototypal model.
There was a piece of code that generated static HTML pages that displayed data, and this was the View. There was another piece that caught input from the browser and used it to do things, and that was the Controller. And then, perhaps, the Model was represented by the database.
That's still not as clear as one might like.
In particular: Where do URLs fit into that pattern? Rails Routes are neither models, views, nor controllers, from the framework's point of view. Other frameworks draw the lines differently -- Ramaze puts routes inside the controller.
I've always thought that MVC was a bit too sloppy. I get what the Model is supposed to be, but the controllers and views are always blurring. For example: If I have a bit of repeated code -- find the username, say, or sanitize this chunk of HTML -- where does that go? Technically, it's part of the view, but you don't want to put too much logic in the view. But it certainly doesn't belong to the model -- the model knows about users, but has no idea which is the "current" user.
As to this particular problem, I've seen two good solutions. One is to throw away MVC for the client side, and use progressive enhancement and AJAH -- that is, HTML instead of XML for the communication. Thus, the client stays lightweight -- it doesn't even have to think about generating HTML, it just pastes HTTP responses from the server right into the document.
The other is to treat it like a separate application. Thus, the server may well have a full MVC pattern (it has to serve something at some point anyway), but any sufficiently complex client code is also a full MVC pattern. Design it the way you would if it was a "fat" client -- you still use a model, it just happens to be a model which mostly makes calls to the server. But your views and controllers don't have to know or care.
Once you get to a certain level of quality/performance it it quite hard for anyone but the technophiles to appreciate any improvement.
With quality, yes, maybe. With performance, absolutely not.
Is HD really that much better than SD?
It is overhyped, I'll admit. And it's not that much better. But it absolutely can be much better, depending what you're watching and how. Most of the time, it's kind of meh -- sometimes (and never from broadcast "HD"), it makes my jaw drop.
But at least here, there's a limit. There are only so many rods and cones in the human eye -- after a certain point, we'll have enough resolution and framerate that we won't be able to tell the difference, or we'll run into some physical barrier (like Planck).
Is a dual core really that much better than a single core?
There are all sorts of things which can use exactly as much CPU as you can throw at them. Unless you're a gamer, most of them don't affect you.
However, one thing that does directly affect you is, ironically, the fact that it doesn't make a difference for most apps -- most apps are mostly single-threaded. This means that, unlike with a single core, if you have something sucking down 100% CPU, you still have a whole extra core. Aside from draining your laptop battery faster, you might not even notice.
Is 100Mbits/sec really better than 20Mbits/s?
Absolutely. It's the difference in a download taking two hours, and a download taking ten hours.
What's more, Blu-Ray bandwidth is 30 mbits. Not that anyone's doing this yet, but at 100 mbits, you could stream a Blu-Ray disc. At 20 mbits, you probably couldn't.
The point here is that power is different than quality. At a certain amount of quality, no one can tell the difference, and no one cares. But power works differently -- you think you've gotten to a point where you have enough power. We all get to that point, sooner or later. And just a bit beyond that point, someone figures out a use for all that power.
A cautionary tale -- "512k should be enough for anybody!"
And indeed it should. 56k Internet should also be enough for anybody.
But we keep coming up with actual uses for all that power. And yes, I frequently do things for which dual-core and 100 mbit fiber are significantly better.
Slashdot Mirror
Interesting. I haven't tried that here -- I do have a virtualized Windows, but it's different enough hardware that I had to call Microsoft to register the bare-metal install after first installing on the VM.
I could also download and then backup during the day in my VM, then restore the backup.
For now, I just suck it up and enjoy my fiber -- only took an hour to download Episode 2 anyway. It is, however, an irritation.
Bad idea, a huge cache is actually less efficient than just grabbing the data from the source in many instances.
In enough others, it's much more efficient. And I'm not just talking about the Web.
Imagine you have 10M items in your disk cache,
I'm on a rather small filesystem -- 365,934 files. This is a laptop -- I tend not to keep more on it than I have to.
It also takes 9 ms to list a directory. That's a listing, not a single file lookup. It's also small enough to be unreliable -- repeating the experiment gives different results.
Now, I haven't tried this lately, but are you telling me that a filesystem with 10 million records would respond slower? Even if you're right, that lookup was still fast enough that it hardly matters -- but I don't think you are. I think an index could be designed to be fast enough.
trying to find a 1x1 pix graphic
There is no good reason to have a 1x1 pixel graphic. Certainly not in a webpage.
in the index of 10M items is going to take MUCH longer than just downloading that file in the HTTP 1.1 stream.
That's a pathological case. I'm also going to guess that it's not enough longer to care about -- especially considering the overall gain in the vast majority of cases, where it's not a 1x1 pixel image.
For example: I know people with capped Internet. Not Comcast-capped, 250-megs-per-day capped. I am sure they would love if YouTube videos were cached for them -- every megabyte helps. It's not like they were doing anything with the other 50 or 100 gigs.
Few people are going to let you install some random driver on their notebook just to access your USB drive.
Oddly, most people I know are going to let me install anything I want. They'll be curious what it is, but they won't actually stop me -- they assume I know what I'm doing.
What's more, most people aren't going to have autorun disabled -- therefore, as soon as I plug in, there's a chance I'm running something anyway.
It's in Ubuntu but what about Debian or CentOS or Sabayon (this being three distros I encountered lately on random computers)?
If someone's running Sabayon, either they have a very good rationale for not having ntfs-3g installed, or they'll thank you for showing them how to get it working.
And a Linux user should have even less of a problem, since these packages are most likely available via a trusted repository -- so they don't have to trust anything from my disk.
The reason we put up with FAT32 is not high compatibility, it's absolute compatibility. You can stick a FAT32-formatted USB drive into any random comouter you encounter and it will definitely mount with no kind of setup neccessary.
So long as it's at least Windows 2000. 98 won't do it.
You're right, of course, but it still seems incredibly stupid that we're using a DOS filesystem because nobody had the presence of mind to distribute something useful with the first USB mass storage drivers.
Jeez, choose one FS and stick with it.
Just like everyone else does? Oh wait...
We've got FAT32 for thumb drives, NTFS for Windows hard drives, HFS+ for OS X hard drives, and ISO9660 and UDF for CDs/DVDs -- several versions of them, in fact, with Rock Ridge extensions, Joliet extensions, plus UDF2...
Now, most distros do stick to the standard pattern of one swap partition and one big root partition, formatted as ext3.
However, just like the rest of the world, we recognize that different situations call for different filesystems. UbiFS is a filesystem sitting directly on flash media (instead of above some wear-leveling ATA-emulating layer designed for FAT). sshfs is a (fuse-based) filesystem for accessing remote filesystems via ssh. Squashfs is a read-only, heavily-compressed filesystem, ideal for use on livecds and DVDs. And then there are the journaling filesystems like ext3.
It would be stupid beyond belief to suggest that we should unify those things into one giant, lumbering, monolithic, bloated filesystem.
Instead of one stable implementation you have this whole business of a dozen half-assed implementations again.
Look at the above filesystems I've mentioned. What is half-assed about them? Please be specific.
If Linux coders were designing "standards", we'd have TCP/IP, TCP/IP2, TCP/IP3, TCP/IP4-beta5-pre46 and what not.
Actually, I'm betting quite a lot of Linux coders were designing them -- and the situation isn't far from what you describe.
We still have ipv4 and ipv6. We also have TCP, UDP, and ICMP. We have implementations of TCP over UDP. We have older protocols like AppleTalk and IPX -- dead in most places, but there's a reason Linux still supports them. We have NetBIOS and DNS. We have Zeroconf and Bonjour.
This right there shows you what's wrong with Linux.
Really?
No, filesystems are actually one place Linux is king -- with the possible exception of ZFS, but that's being rectified. We support just about everyone else's filesystems -- from 9pfs to sysvfs, and everything in between. With FUSE, we even support a few filesystems that won't go into the kernel, for technical or legal reasons.
In fact, it speaks quite loudly about the quality of desktop Linux that you think this is what's wrong with Linux. You could have chosen to complain about how slow suspend/resume is on some devices. You could have raged about the lack of support for some obscure wireless card, or whined about being forced to modify your kernel commandline for your touchpad to work.
These might all be valid complaints, but you didn't raise them. Instead, you chose to complain about how many filesystems we have -- how dare we provide so much choice!
And seriously, what kind of fucking ridiculous name is Tux3?!
The same kind of fucking ridiculous name that FAT32 is. Or maybe you like HFS Plus?
Actually, if you want a filesystem usable by everyone it will definitely have to come from Microsoft.
It doesn't much matter whether they cooperate. Even if they insist that the Windows boot device continue to be NTFS, there's a standard way to write filesystem drivers for Windows (ext2 is already supported), and it's easy to put just about everything except Windows itself on another partition, if we have to. (Which we probably won't -- we could even slipstream it in.)
So, we can force the issue.
And suppose I have a portable hard drive, which I want to make sure is readable everywhere -- all I have to do is make a separate FAT32 partition with all the relevant software on it for Windows and OS X to read the other partition.
ntfs-3g is hardly a default package in most distros so no dice.
On Macs, it's supported via MacFUSE, which users still need to install. On Ubuntu, it absolutely is a default package, already there even on the livecd.
You just have to draw the layers differently.
I've repeatedly proposed something, only to find that ZFS already implements it: Define one layer which is solely responsible for storing your bare primitives, like a sequence of data. It is the FS-level equivalent of malloc/free.
Then, implement everything else on top of that layer. Databases could sit directly on the layer -- no reason they need to pretend to create files. Filesystems would sit on that layer, implementing structures like directories and POSIX file permissions.
Of course, while I'm at it, I have this other idea -- unify disk caches. It should be possible for me to allocate my entire available free space as a shared cache, between my package manager, browser, everything -- then, provide a common mechanism for reclaiming that space when something wants disk space.
True. However, a true native port would very likely include the existing x64 support. And no, I don't really get that advantage, as a single 32-bit process (on Windows) is limited to, what, 2 gigs of RAM? The only advantage would be if I needed the other 2 gigs for something else, rather than 1.5 gigs.
I still would also gain the benefit of being able to download while I work, having a supported solution, not having to reboot, being able to instantly join a game from an IM, and so on.
It does, however, require some variant of Flash -- I applaud efforts like Gnash, but ultimately, it's exactly as much a "solution" to Flash as Wine is a solution to a lack of native apps.
It means that ultimately, I have to use the real Adobe Flash, because some things will require it. About the only way that will change is if Adobe either releases the Flash source, or starts heavily supporting one of the free alternatives.
Wall Street is only a small part of it. This is about much longer, larger trends -- like, "Is the American Empire about to fall?"
I can almost rationalize away making Susan Calvin a love interest
Having not seen the movie, I can say I probably wouldn't mind. Even when Asimov did sex, it was pretty dry -- he didn't write characters well at all, he wrote ideas. My favorite book of his was Bicentennial Man, which was co-authored with someone who knew emotion.
2001 would certainly be a failure, but not for the reasons you imagine.
It was, in fact, so crammed with special effects -- effects which would be boringly easy to do today -- that when you get over that, it's boring.
Not "boring" as in "no explosions", but "boring" as in "Let's waste several minutes of our lives watching these two objects in space get closer and closer together, and finally dock."
My theory is that, well, the movie was released in the late 60's -- 1968, one year before the Summer of Love. So, when it was released, it was an amazing movie, mostly because so many moviegoers were stoned out of their minds.
I don't disagree with your point -- I don't usually mind a movie that's simple, yet crammed with special effects. But I much prefer a movie that makes me think. And there are too few of those, scifi or not.
Because it's actually more painful to run it in Windows, for some of us. Here, let me count the ways:
Linux has pretty good 64-bit support. The last remaining broken piece was browser plugins -- Java has been ported, and Flash will be soon. Windows 64-bit sucks before Vista, and Vista sucks in so many other ways that 64-bit is hardly a concern.
And yes, Valve games can use 64-bit and multicore. And I do have 4 gigs of RAM, which means XP can only see 3.5 gigs.
I also run Linux for everything other than games. That means, not only is there the irritation of having to reboot -- somewhat mitigated, as I can hibernate one and boot another -- but that I have to maintain Windows, which is much more work for me than maintaining Linux -- on top of which, I still have to maintain Linux. (Example: Ever try to hunt down XP drivers for a made-for-Vista laptop?)
Steam also insists that I install/update games via its client. That's great, if I'm running Windows anyway -- and I'm on fiber, so it's fast. But it means I can't download while on Linux. What's more, I can't play a Steam game I've already got while I wait -- as soon as Steam sees me playing a game, it kills all downloads. I suppose it's to keep me from lagging -- thanks, but it reacts the same way if I'm playing a single-player game.
If there was a Linux client, I'd just leave it running and not care.
And then there's the fact that Steam itself is a good deal more than just a game client, now -- assuming they've finally gotten the Friends feature working, it's also an IM client. That would be nice -- a friend IMs me, inviting me to a game, and rather than rebooting, I just click "yes" in that window -- and he can IM me from the game, he doesn't have to alt+tab to some other client to a Pidgin-friendly service.
Now, granted, I could run games under Wine. I do, for some games -- MMOs, I pretty much demand that they run windowed on Linux, because I absolutely do multitask with those. But with Steam, there's a performance hit (all Valve games are DirectX only, now), there's again 32-bit only (no Win64 support in Wine yet), and none of it is supported, meaning if I have any problems, I'm on my own.
Still, it's not as though there would be no benefit. Even if these end up being winelib'd apps, at least they're supported, and it's a step in the right direction -- next up would likely be an OpenGL port. It also means that some of the non-Valve games on Steam which have native Linux clients would also work in Steam.
The Linux Dedicated Server distribution includes all kinds of things that aren't needed -- including Windows DLLs, sound files, etc.
I'd like to see an actual comparison with the current Linux dedicated server before I jump to conclusions.
That said, I'll also be first in line if they ever do release a Linux client.
If the device manufacturers had put the firmware in ROM (flash/EEPROM/whatever) attached to the peripheral rather than downloaded by the driver, does that really change anything?
If the license forbids you from distributing the binary blob in the driver, it changes quite a lot.
my hope is that the Ubuntu/Fedora will not change their approach.
I don't care much. I never used Ubuntu with any illusions that it would be 100% "free software" -- despite my best efforts to the contrary, I occasionally have to communicate with people via Skype. Despite the HTML5 effort, YouTube still requires Flash. And no matter what my ideology, if I'm a gamer, I'm going to be using proprietary software.
But it is nice to keep the definition clear. I have no problem with proprietary software, but let's not pretend it's something else.
I would rather have a solid card with a binary blob than a "free" card that stinks.
Nvidia is, unfortunately, an example of a solid card with a binary blob that stinks.
Go ahead and piss of companies that supported Linux for years.
By doing what?
I'm sorry, I never called nVidia "evil", or anything of the sort. Certainly, I'm grateful that I'm able to buy pretty much any nVidia card and have a better chance of finding working drivers for Linux than for Windows.
(True story: This laptop shipped with Ubuntu. Yet the only drivers available from the Dell website were for Vista, and nvidia claimed that Dell are the only ones allowed to distribute an XP driver. So I actually had to get a tech to give me a download link. On Ubuntu, it Just Worked, even when I reinstalled 64-bit...)
However, I'm not doing them any favors by pretending they have good drivers. They don't. Intel frequently beats them for 2D performance, and for things like Compiz and KDE4 -- which is sad, when you consider how weak the current Intel cards are. And I've had more than a few nvidia-driver crashes on an otherwise-functioning system.
Were the driver open, these problems might still exist, but at least I'd have a chance of solving them. As it is, the only thing I can do is idly threaten to go ATI next time.
All of which is customer feedback, which is something many companies devote a lot of time and effort into collecting. If that "pisses them off", then they deserve to die.
Is it any more free than having a distro that's free but not having the freedom to run it on your hardware because it's completely useless?
Having a distro like that serves at least one practical purpose: I can use it to evaluate a given set of hardware for compatibility. That can inform future purchasing decisions.
For instance, having used Linux, I now know that I will never knowingly buy a Broadcom wireless card -- or, very likely, anything from Broadcom -- even for devices I don't plan to run Linux on.
This is just taking that one step further.
it's not like I could buy a complete set of open hardware
Actually, under certain, limited circumstances, you can. I believe the OpenMoko Freerunner was such a device.
Yeah... which then chops off more of the picture than any overscan ever did.
I'm talking about the whole process -- which, for me, is:
- Boot livecd
- Backup everything
- Reformat
Then, there's the pre-emptive steps:
- Boot livecd (or other OS)
- Take disk image of software partition (with ntfsclone)
- Before any major change, restore that image, make the change, then save a new one
Combined with the fact that I don't use Windows very much, malware is pretty much a non-issue for me. I don't even have any kind of anti-malware beyond the standard Windows firewall.
I was deliberately testing only reads. If I was to test writes, it would probably be if=/dev/zero, of=whatever. But that would allow filesystem buffering to become more of a factor...
A quick test shows somewhat less than 60 megs/sec. But then, I don't really need writes to be as fast, simply because I'm almost never writing that much.
The hugest problem is latency.
Surely you jest. I use Gmail every day, and it's lightning fast on pretty much any connection. About as fast as I could ask for with the keyboard shortcuts.
they all suffer from the most bizarre and twisted coding problems I have ever seen.
Be specific.
CSS is STILL fundamentally broken and behaves erratically as evidenced by the box model, which you cannot to behave correctly browser to browser platform to platform.
Are you going to tell me that a native app has it any easier with cross-platform compatibility?
If you're going to talk about a library, that's fine -- consider that there are plenty of libraries out there for javascript-as-a-client which make the CSS issue mostly go away.
DOM still has really niggling and dumb problems after all these years as well.
Like what? Any which aren't already abstracted away by things like jQuery?
In the final analysis what we all want is a set of tools that will allow us to design a screen with a particular look and feel that will be presented exactly the same no matter where it is displayed.
Incorrect.
What I want is a set of tools that will allow me to design a screen with an independent look and feel, that will be presented exactly the way the user wants it to be.
If I use ctrl+mousewheel to change the font size, your app should be able to handle it. That's actually a feature that's sorely missing from a lot of desktop applications.
Today you have to combine three very different styles of design and coding, they are HTML, CSS and Java Script to come up with anything that is remotely useful for doing anything more then displaying text.
It's called a domain-specific language. On the server, you most likely have to combine some form of SQL with your application, and when things go wrong, you'll want to be able to understand HTTP.
HTML, Javascript, and CSS all do fundamentally different things.
HTML is a markup language -- it does markup much better than Javascript does (with the DOM). Well enough, in fact, that at least a couple GUI toolkits allow you to use some HTML-like syntax for rich text.
We need to glue all those together in a coherent manner that brings it to a true object model.
You're making another large assumption -- that Object-Oriented Programming is the be-all and end-all of methodologies.
To change the background I have to use Java Script to interrogate DOM to get to the right CSS selector and change that and my god what a pain that is!
That's why we have jQuery.
Would it not be simpler to just do this?
ImgBox = Box.New([styleReference]);
What's Box, and where does it get defined? How about styleReference -- how does that get defined? And how do I then take my ImgBox and insert it into the document? How do I assign all of the children of the old box to this new one?
If styleReference was defined in CSS, then we have something that does what you want already. It's just as simple, but unlike your example, it actually works, and does cover all of the above:
$('#my_div').removeClass('foo').addClass('bar');
Further all since java scipt is loaded when the page is loaded it should be trivial to have static events pre-built for each component
Depending what you mean by "OnExit", this does, in fact, exist already. Slightly different names and syntax, but the idea is the same.
would it not follow that that the following call would be far more appropriate then what we do now?
Not really. Again:
$('#some_div').style('backgroundImage', 'url(/webroot/images/mygreatcorpimage.png)'{;
I can save that initial reference and do it your way:
var ImgBox = $('#som
Are you telling me that screenreaders are incapable of handling generated HTML?
Repeat after me:
Javascript is not Java.
Java is not Javascript.
most scripting languages discourage abstraction because they aren't set up to enforce OOP concepts.
Wait, what? It's not possible to encourage something without enforcing it?
Javascript doesn't force anything, and yes, you can create BASIC-like spaghetti. But a bad programmer can create BASIC-like spaghetti in any language. A good programmer will take the time to learn Javascript's prototypal model.
There was a piece of code that generated static HTML pages that displayed data, and this was the View. There was another piece that caught input from the browser and used it to do things, and that was the Controller. And then, perhaps, the Model was represented by the database.
That's still not as clear as one might like.
In particular: Where do URLs fit into that pattern? Rails Routes are neither models, views, nor controllers, from the framework's point of view. Other frameworks draw the lines differently -- Ramaze puts routes inside the controller.
I've always thought that MVC was a bit too sloppy. I get what the Model is supposed to be, but the controllers and views are always blurring. For example: If I have a bit of repeated code -- find the username, say, or sanitize this chunk of HTML -- where does that go? Technically, it's part of the view, but you don't want to put too much logic in the view. But it certainly doesn't belong to the model -- the model knows about users, but has no idea which is the "current" user.
As to this particular problem, I've seen two good solutions. One is to throw away MVC for the client side, and use progressive enhancement and AJAH -- that is, HTML instead of XML for the communication. Thus, the client stays lightweight -- it doesn't even have to think about generating HTML, it just pastes HTTP responses from the server right into the document.
The other is to treat it like a separate application. Thus, the server may well have a full MVC pattern (it has to serve something at some point anyway), but any sufficiently complex client code is also a full MVC pattern. Design it the way you would if it was a "fat" client -- you still use a model, it just happens to be a model which mostly makes calls to the server. But your views and controllers don't have to know or care.
Once you get to a certain level of quality/performance it it quite hard for anyone but the technophiles to appreciate any improvement.
With quality, yes, maybe. With performance, absolutely not.
Is HD really that much better than SD?
It is overhyped, I'll admit. And it's not that much better. But it absolutely can be much better, depending what you're watching and how. Most of the time, it's kind of meh -- sometimes (and never from broadcast "HD"), it makes my jaw drop.
But at least here, there's a limit. There are only so many rods and cones in the human eye -- after a certain point, we'll have enough resolution and framerate that we won't be able to tell the difference, or we'll run into some physical barrier (like Planck).
Is a dual core really that much better than a single core?
There are all sorts of things which can use exactly as much CPU as you can throw at them. Unless you're a gamer, most of them don't affect you.
However, one thing that does directly affect you is, ironically, the fact that it doesn't make a difference for most apps -- most apps are mostly single-threaded. This means that, unlike with a single core, if you have something sucking down 100% CPU, you still have a whole extra core. Aside from draining your laptop battery faster, you might not even notice.
Is 100Mbits/sec really better than 20Mbits/s?
Absolutely. It's the difference in a download taking two hours, and a download taking ten hours.
What's more, Blu-Ray bandwidth is 30 mbits. Not that anyone's doing this yet, but at 100 mbits, you could stream a Blu-Ray disc. At 20 mbits, you probably couldn't.
The point here is that power is different than quality. At a certain amount of quality, no one can tell the difference, and no one cares. But power works differently -- you think you've gotten to a point where you have enough power. We all get to that point, sooner or later. And just a bit beyond that point, someone figures out a use for all that power.
A cautionary tale -- "512k should be enough for anybody!"
And indeed it should. 56k Internet should also be enough for anybody.
But we keep coming up with actual uses for all that power. And yes, I frequently do things for which dual-core and 100 mbit fiber are significantly better.