In the link you posted, the admin found three uberblocks (there are supposed to be four). ZFS correctly made multiple uberblocks, per design. It appears that all three were corrupt.
ZFS keeps a history of the last 256 uberblocks in four different places in the pool. So even if all copies of the most recent uberblock got corrupted, it could still fall back to one of the older ones. You'd maybe loose the last few minutes of work, but that's not nearly as catastrophic as loosing the whole pool.
It could fall back, but it doesn't, it rather panics the kernel. This is where a userspace fsck would help, for examply by giving you the choice to safely invalidate the last uberblocks. I was not feeling very comfortable when I wrote the dd/ud script that automated that task, but I had nothing to loose at that point.
The silent corruption was just an example. It doesn't matter what causes the corruption. But _if_ you end up in a situation like the admin or me, you have to resort to such ugly tricks to recover your pool. And that is something I'm not willing to accept on a production system - or any system at all for that matter.
Even if you have a 100% bugfree drive firmware, silent data corruption is still possible (resilience against silent data corruption is one of ZFS's selling points!). Filesystems that can't handle that simply have no place in todays world. The problem is that one flipped bit can cause ZFS to think that the whole pool is unusable - even though it keeps redundant copies of the metadata which it then completely ignores! What for does it keep the copies then?
Every disk will corrupt eventually, it's just a matter of time. Not even the best hardware will help you there. So the question is, how well does the filesystem catch these errors and correct them. It turns out, ZFS is really bad at this, as it can get into a state where you can't even import the pool (where zpool either stops with an error and in worse cases causes a kernel panic). There have been numerous bug reports on the zfs mailing list and the opensolaris bug tracker. So far nobody seems interesting in fixing those.
My pool got corrupted in such way. I had to manually poke around the filesystem and invalidate metadata until zpool was able to import the pool. Something that a 'fsck' could have easily done, but Sun refuses to create such tool because, according to them, ZFS is robust enough.
All credits go to this guy who had the idea to invalidate the uberblocks directly on the disk: http://opensolaris.org/jive/message.jspa?messageID=318457#318457
http://www.apple.com/safari/features.html -
Safari 4 introduces the Nitro JavaScript engine, an advanced bytecode JavaScript engine that makes web browsing even faster. In fact, Safari 4 executes JavaScript up to 6 times faster than Internet Explorer 8 and up to 4 times faster than Firefox 3.1.
Of course two different users can't connect to the same screen session. That would be a big security risk. Look into/var/run/screen and you'll see that only you have access to the directory where your screen sockets are stored. Maybe it's possible to fiddle with the file permissions, but I wouldn't recommend it. Just create a new use that all the people have access to and tell them to use 'screen -x'
You do understand, of course, that KDE, Gnome, and XFCE are windows managers and not operating systems right? And you don't seem to understand, of course, that KDE, Gnome and XFCE are not window managers but desktop environments (DE).
Xinerama, for instance, doesn't support 3D on both monitors, TwinView does, but then you don't get the "xinerama aware" benefits, etc.. Windows is rock solid and bone simple in this regard. The nvidia driver can (and does by default IIRC) export Xinerama info for TwinView configurations. And btw, Xinerama should die, long live XRandR 1.2:)
I was under the impression that OpenGL wasn't platform dependent, so if 2.0/3.0 will be released it won't be able to use the same GPU features on WinXP and Vista?
DX10 and OpenGL are nothing than just APIs to the GPU! You can emulate both ways, IIRC MS first tried to emulate OGL using DX in the early Vista days. OGL 2.0/3.0 will have DX10-like features. Maybe some even are possible to emulate in OGL 1.5.
WWN isn't updated because nobody does it, but the development progressed considerably since then and I would say DX9 is in very good shape now. DX10 headers and stubs was a google SoC project, which unfortunately didn't go very well, but alas, the effort is there. In some cases wine is faster than windows, especially now that you read how slow vista is I think wine has some advantages.
>... game publishers only release DX10-compatible versions...
By that time the Wine (www.winehq.org) team will have released DX10 libraries that use opengl and thus can run on Win XP or older (and of course Linux!).
Is it just me or do you also have the impression that the whole X11 server architecture is way too complicated.
Xorg (the xserver), dri, drm, kernel modules, Xgl, mesa.
What amazes me, Xgl rund on top of the xserver (Xorg), because theres something with dri that Xgl can't do directly.
I've created a simple (and by simple I really mean simple) 'xserver':
the basic idea was to take an existing API and build the 'xserver' on top of it, the API is OpenGL. Windows are special objects in memory that can be shared between the client and the server. The client creates an window and tells the server 'hey, there's a user and he/she wants to see this window, please put the window with ID xyz onto the first monitor so he/she can see it'. and the server loads the object and puts it into the frontbuffer. and the client can draw (write) to the window and the server reads from it. and both the server and client use the same API (OpenGL) to draw things, the server into the frontbuffer, the client into the window object.
Of course there's a tiny API for handling these objects, but that's only very few functions, maybe 15, that's enough.
And it works. Now if someone writes a driver that makes use of the GPU/video ram, this could be really fast. Currently it supports the mesa software opengl library for rendering.
Slashdot Mirror
or we'll blow ourselves up..
reminds me of http://www.endofworld.net/
In fact, there are many things that are happening now which makes me think: "Are they doing this on purpose? Or are they retarded?"
Definitely retarded (see http://en.wikipedia.org/wiki/Hanlon's_razor).
Replicators in Stargate: http://en.wikipedia.org/wiki/Replicator_(Stargate)
In the link you posted, the admin found three uberblocks (there are supposed to be four). ZFS correctly made multiple uberblocks, per design. It appears that all three were corrupt.
ZFS keeps a history of the last 256 uberblocks in four different places in the pool. So even if all copies of the most recent uberblock got corrupted, it could still fall back to one of the older ones. You'd maybe loose the last few minutes of work, but that's not nearly as catastrophic as loosing the whole pool. It could fall back, but it doesn't, it rather panics the kernel. This is where a userspace fsck would help, for examply by giving you the choice to safely invalidate the last uberblocks. I was not feeling very comfortable when I wrote the dd/ud script that automated that task, but I had nothing to loose at that point.
The silent corruption was just an example. It doesn't matter what causes the corruption. But _if_ you end up in a situation like the admin or me, you have to resort to such ugly tricks to recover your pool. And that is something I'm not willing to accept on a production system - or any system at all for that matter.
Even if you have a 100% bugfree drive firmware, silent data corruption is still possible (resilience against silent data corruption is one of ZFS's selling points!). Filesystems that can't handle that simply have no place in todays world. The problem is that one flipped bit can cause ZFS to think that the whole pool is unusable - even though it keeps redundant copies of the metadata which it then completely ignores! What for does it keep the copies then?
Every disk will corrupt eventually, it's just a matter of time. Not even the best hardware will help you there. So the question is, how well does the filesystem catch these errors and correct them. It turns out, ZFS is really bad at this, as it can get into a state where you can't even import the pool (where zpool either stops with an error and in worse cases causes a kernel panic). There have been numerous bug reports on the zfs mailing list and the opensolaris bug tracker. So far nobody seems interesting in fixing those. My pool got corrupted in such way. I had to manually poke around the filesystem and invalidate metadata until zpool was able to import the pool. Something that a 'fsck' could have easily done, but Sun refuses to create such tool because, according to them, ZFS is robust enough. All credits go to this guy who had the idea to invalidate the uberblocks directly on the disk: http://opensolaris.org/jive/message.jspa?messageID=318457#318457
http://www.apple.com/safari/features.html - Safari 4 introduces the Nitro JavaScript engine, an advanced bytecode JavaScript engine that makes web browsing even faster. In fact, Safari 4 executes JavaScript up to 6 times faster than Internet Explorer 8 and up to 4 times faster than Firefox 3.1.
Of course two different users can't connect to the same screen session. That would be a big security risk. Look into /var/run/screen and you'll see that only you have access to the directory where your screen sockets are stored. Maybe it's possible to fiddle with the file permissions, but I wouldn't recommend it. Just create a new use that all the people have access to and tell them to use 'screen -x'
Is there any end? No, and you were right with the carrot: http://www.worldofwarcraft.com/community/comics/gallery.html#139
Don't underestimate hamsters.. especially wereHamsters!
eol.org, all I can see in it is 'end of life'
You're just not patient enough. That time will come, I can promise you that. Now lean back, relax and watch how the america slowly deteriorates.
I was under the impression that OpenGL wasn't platform dependent, so if 2.0/3.0 will be released it won't be able to use the same GPU features on WinXP and Vista?
DX10 and OpenGL are nothing than just APIs to the GPU! You can emulate both ways, IIRC MS first tried to emulate OGL using DX in the early Vista days. OGL 2.0/3.0 will have DX10-like features. Maybe some even are possible to emulate in OGL 1.5.
WWN isn't updated because nobody does it, but the development progressed considerably since then and I would say DX9 is in very good shape now. DX10 headers and stubs was a google SoC project, which unfortunately didn't go very well, but alas, the effort is there. In some cases wine is faster than windows, especially now that you read how slow vista is I think wine has some advantages.
> ... game publishers only release DX10-compatible versions ...
By that time the Wine (www.winehq.org) team will have released DX10 libraries that use opengl and thus can run on Win XP or older (and of course Linux!).
You have never tried running the remote assistant (which is basically remote desktop) in WinXP over a 128kbit ADSL line, did you?
I don't know about VNC, but I could play UT200? over a 100MBit LAN, in a time when we had only a hub, no switch in out little network.
Try to play a game on remote desktop.
Can I go to the US and sell hard drugs?
I'm just asking because it's legal where I live, and if the world was like you think, I could do that.
Is it just me or do you also have the impression that the whole X11 server architecture is way too complicated.
Xorg (the xserver), dri, drm, kernel modules, Xgl, mesa.
What amazes me, Xgl rund on top of the xserver (Xorg), because theres something with dri that Xgl can't do directly.
I've created a simple (and by simple I really mean simple) 'xserver': the basic idea was to take an existing API and build the 'xserver' on top of it, the API is OpenGL. Windows are special objects in memory that can be shared between the client and the server. The client creates an window and tells the server 'hey, there's a user and he/she wants to see this window, please put the window with ID xyz onto the first monitor so he/she can see it'. and the server loads the object and puts it into the frontbuffer. and the client can draw (write) to the window and the server reads from it. and both the server and client use the same API (OpenGL) to draw things, the server into the frontbuffer, the client into the window object. Of course there's a tiny API for handling these objects, but that's only very few functions, maybe 15, that's enough.
And it works. Now if someone writes a driver that makes use of the GPU/video ram, this could be really fast. Currently it supports the mesa software opengl library for rendering.
the whole world say 'amen' in the church and not 'alady'... but yet we don't say that the catholic church is sexist...
Then again: I urge caution--supposing Microsoft has already patented such things in Longhorn? The F/OSS community could be in serious trouble...
Not in europe... we're never gonna have software patents.
I'd say cry..
it's because of them (american banks' poor security) that we recieve these mails.
The problem is, the mail comes from a perfectly valid domain (yahoo etc), but the link inside points to an invalid domain.
So unless sendmail scans the message for links, this isn't going to work.