From the CMS e-commentary."..the beams were extremely stable during this period and had a very long lifetime."
Yes, but only for about two minutes, then they were dumped because the protection system was acting up. That's a major PITA when running such machines. The protection system is overly sensitive and needs to be carefully tuned to safely detect "safe" conditions and only report minor deviations. Since it has never been run at that energy with beam it it, there are still a few things to sort out, which needs a bit of time (and a certain amount of trial and error). Well, better safe than sorry.
And, by the way. The beams were stable is not what is meant by the term "stable beams". The latter usually refers to the state when they are actually declared stable by LHC operations. When they are declared stable, the experiments can safely turn on their detectors since LHC then guarantees that no beam will go awry and shoot particles into sensitive parts while they are on high voltage. When LHC declares stable beams, this usually means that they are well measured, well positioned and brought to collisions. The "stable" referred to in the blog just means that they were staying in the LHC and not getting into troublesome resonances and scratching collimators and such. (which is a good thing, since beam optics depend on the beam energy, which means LHC was able to keep things under control while ramping, which by the way they did in an amazing short amount of total ramp attempts, which IIRC you can count on one hand)
Actually, the quenches themselves are not the problem, these are quite under control and during the so-called training campaign something that is even deliberately induced.
The problem here is more a chain of unfortunate events, and something that wasn't expected during design.
Basically what happened is: - faulty electrical connection caused the power supply to trip (i.e. detect some problem and shut down) - fast discharge was triggered as a consequence - during fast discharge the current couldn't be handled by the faulty connection, causing an electrical arc - the arc burnt a hole into the insulation
This is the first thing that hadn't been considered in the design. The cold mass can withstand a very high helium pressure. Helium is not expected to go in the vacuum outside of the insulation (which is there as a thermal shield).
Then, the next problem: - the electric arc caused some bad electrical fluctuations, causing the quench protection system in several magnets to think there was a quench - as a consequence, the quench protection heaters then actually induced real quenches - as a consequence, a lot of Helium got evaporated, causing the Helium pressure in the cold mass to increase sharply
This wouldn't have been a real problem, hadn't there been the hole caused by the arc.
Now the Helium entered the thermal shield around the cold mass with high pressure, causing emergency shutters installed all 107 meters to close, which are there to protect the vacuum in the rest of the magnets. Unfortunately they were maximally designed to withstand a pressure of regular atmosphere and not the Helium under high pressure. As a consequence they were completely torn by the pressure, causing connections between magnets to be damaged and even more Helium to be released. Several hundreds of meters of tunnel were affected by this, which leads to my personal conclusion that the pressure must have broken several shutters in both directions, until they could finally hold.
So, as a consequence, the actual faulty electrical connection was a small problem compared to the chain reaction which caused in total 29 magnets to be damaged.
(Disclaimer: Personal interpretation of the incident report, there might be flaws in it)
Netscape didn't cost anything, but it was closed source. At admit it, at that point it also was majorly broken. That's when Netscape was dead and decided to release the source code they started to work on it and it was basically completely rewritten.
A lot of volunteers were involved at that point, resurrecting the beast. It's only when things started to look like something when Netscape jumped onto the bandwagon and put some muscle behind it. But that's different.
Well, does grub work with LVM? Can grub set set command line for *only* the next reboot? (lilo -R)
Two big reasons why I don't use grub. And I personally think that the concept is broken. Filesystem drivers live in the operating system, not the boot loader.
Lilo reads a list of sectors where to find the kernel and initrd and parts of itself, writes them to the disk and tells the boot sector where to find that stuff.
So the boot part of lilo doesn't need to know anything about the filesystem or disk structure, it just loads the stuff and leaves the complicated part to the operating system. And it doesn't write anything into any reserved parts of the disk, just the boot sector.
And I don't need the interactive part of the boot loader anyway, since I can't access the console of that machine, which is, by the way, an AMD64.
lilo has never failed me, and while its concept is simple, it can do a lot, supports every kind of filesystem on weird hard disk / volume configurations. The only thing it could need is a major rewrite, the code has gotten really messy.
Actually, there is something like a backwards compatible API. At least under Linux, I don't know what the other architectures are doing.
In the IPv6 address space there is the::ffff:xxxx:xxxx address range, where xxxx:xxxx is an actual IPv4 address. (also sometimes written as::ffff:###.###.###.###)
This means that applications can use the IPv6 sockets API but then use the old IPv4 stack. This means that a newly written application can use the IPv6 API and still work with the current Internet without the explicit need to support both. A lot of OSS software already supports this.
You can find this in your logs when you have loaded the IPv6 module.
Jul 1 14:35:59 server imapd: LOGIN, user=xxxxxxxx, ip=[::ffff:192.168.xx.x], protocol=IMAP
Also there are some new APIs in the C library that make it easy to write completely (or mostly) protocol-independent software.
Like the "getaddrinfo" library call. It will do a hostname lookup (via DNS,/etc/hosts or address parsing or whatever) and return a list of "addresses". The address can be an IPv4 or IPv6 address, you don't really need to care, just pass the returned information to the socket calls and you have your stream or datagram file handle. Even if the added IPv9 or something else, your application will most likely just work since it doesn't care.
Most applications are rather easy to port to either the IPv6 API or the protocol independent API. What's more complicated is to port ACL checking and these things because that's where applications start parsing the addresses itself. Or if applications want to store address data or transmit it inside their protocol.
I'm using PHP on a pre-forking Apache2 now and it's working like a charm.
Actually, PHP could add locking around library calls that are not thread safe. While PHP is easy to use and offers a lot of functionality the PHP code for the extensions is just a big mess design-wise.
Re:I would love to see CCM for X
on
The Power of X
·
· Score: 3, Informative
That's not an X issue.
I think Owen Taylor is planning to implement this in Pango. It's all but trivial.
Hans, can you now please explain, is atomicity enough to expect that the ReiserFS will survive power out, or not?
Yes, that's exactly what "atomicity" refers to. After a crash you'll find the filesystem in a consistent state. You'll either find an atom fully commited or not.
In short, is it without "data logging" as safe as NTFS or is it still not?
It's safer than NTFS. Because it's fully atomical (well, in respect to crashes, no isolation at runtime), NTFS is not.
Other linux filesystems (ext3, reiserfs v3) usually distinguish between, data=writeback, data=ordered and data=journal.
The first two are just guaranteeing atomicity for metadata writes, only the last one for everything.
reiser4 is atomic by default (because it's not a journal bolted on, but by atomic by design), that means it's as safe as data=journal, just without the journalling overhead most of the time.
That was because reiserfs only hat a writeback journal then. The means that it could happen (very often) that the metadata was written before the actual data was and you would end up with random data in the files that were written just before the crash.
I know it because I had the same problems.
But the current 2.6 kernels have a lot of improvements. reiserfs now also has data=ordered and data=journal journalling modes (with ordered-data being the default now). This means that the actual data is written before the metadata is committed. I've never had those problems again.
And, BTW, it's hardly the fault of the filesystem that you lose some data if your system crashes.
The current reiserfs in 2.6 also has a lot of other improvements. A better block allocator, quota and ACL support. If you need those for 2.4, SUSE has had the patches in their kernels for some time now.
DO NOT make a database driven filesystem. Some day we will have a true, document based desktop paradigm (OpenDoc anyone?) but probably not for several years, until then we need SPEED.
Well, filesystems are more or less some kind of database.
Especially the Reiser (3/4) filesystems come very close to being a database.
The database is one big tree. You can see it as (in SQL view) like a single table, where the primary key is indexed and the actual data (the objects) can be of different types.
These types are:
file contents ("blobs")
stat data ("inodes": rights, owners, etc... of a directory entry)
directory (a list of names)
The root directory (/) has a known key, where it can be looked up. There you'll find a "directory" item. It contains a list of names, each name also has a key. Using this key you can find the stat data for that file or directory list or the actual file data.
This data can be located anywhere in the tree, even small parts of file content (like the end of files that don't fill up a block so it would be a waste of space to store it in a full block).
Using this approach everything becomes dynamic. And also very fast because if you have a lot of file, you can write all the data into a contiguous region on the disk and don't have to update some fixed positions on the disk.
Now, reiser4 takes this approach to an extreme:
Concentrate on making tree operations very fast
avoid journaling (need to write twice) when possible, write everything to a new (free) location, update the pointer to that subtree later (commit!) which also invalidates the old subtree
don't distinguish between data and metadata, so everything becomes atomic
extents instead of blocks
The clue is:
the core, described above, is indeed only a flexible and very fast database with atomic operations
the actual filesystem is completely implemented using plugins
a plugin for the disk storage (how the tree and extents are stored on disk, how data is organized)
plugins that tie the database core to the Linux filesystems, plugins like "file data", "directory listing" and "statdata"
These default plugins make a filesystem from the database. It's just like reiserfs3 now, just faster.
BUT: You can now add plugins if you want. Plugins to store compressed or encrypted files. Plugins to store additional metadata alongside the files. It's basically the file system of the future. Because it's extensible without changing the disk format.
The reiserfs block allocator has some improvements in the latest 2.6-mm kernel.
The main problem with p2p is that the filesystem don't allocate space for the file from the beginning even if the file is shown with its full size in the directory. The blocks are allocated when actual data is written. Since writes occur randomly and only very slowly this is some sort of nightmare for the filesystem.
No, actually the middle floor will have no gravity (geostational orbit).
The top orbit will have "gravity" in exactly the opposite direction because it's spinning faster than than the required speed to stay in orbit. It has to pull on the cable to keep it from falling down.
It is somewhat like going through the earth. As deeper you go the gravity will diminish. In the middle of the earth: None. On the other side the gravity will increase again but in the opposite direction.
Well, the Matrix Reloaded Trailer also had an official 100Mb version. 1000 Pixel wide, awesome quality.
But I fear that a lost of space was wasted by the quicktime mpeg4 video codec, I recompressed it using the ffmpeg mpeg4 compatible codec, the result was about 70Mb, but without any visible artifacts though it was just recompressed.
No. The equivalent to C+=1 is ++C, not C++. The result of C+=1 (apart from increasing C by 1) is C+1, while the result from C++ is still the old C. You can write that as an expression using a comma: (C+=1,C-1) - that means that C is increased by one but the whole thing returns the new value decreased by one again (thus the old value of C).
> But portable??? I'm serious, does it currently run on BSD, OS X, Windows, and Linux? And if so, then how much bloat does it add?
Sure. The libraries are basically standard C. The optional thread library has implementations for pthreads and win32 CriticalSections. And there are even some additional compatibility wrappers to make some things more portable (e.g. listing directories).
They are just utility libraries or foundation libraries to build more functionality on top of it. Especially the gobject library is great as a foundation to do modular programs.
In my last project, I used glib from the ground up. I wrote several thousand lines of code before testing it. I made some very aggressive use of glib and gobject. After the code compiled and did not give any runtime warnings anymore it did not contain a single memory leak (verified using valgrind).
glib containts a lot of useful things: lists, trees, hash tables, memory pools, string handling functions and a lot more, everything thread safe.
gobject contains tools on top of glib like "classes" and "objects". It's not the same as in C++ or java, but also very useful. Runtime classes oder data types, generic object properties, reference counting, signal callback, runtime type checking, etc...
The code ist now full of g_... and it took longer than usual because I had to read the documentation, but I think these libraries are very great, and provide a solution for nearly everything that has to do with abstract data types and dynamic memory allocation.
You won't be able to test the programs you're coding.
Does it also mean that sites with javascript need to come up with some form of authorization in order to make it run?
Or, generally, does every scripting language (that is allowed to run) need to check the authorization of the scripts? If it doesn't, you have a potential security breach again...
What about shell scripts, well... "batch files"? Would it be allowed to write some?
Hmmm. To me, this sounds like bullshit. It isn't possible to secure electronic systems. People (not all, but at least some) will always be able to control machines somehow.
Even if you need mod chips. Or even crack the certificate.
Slashdot Mirror
From the CMS e-commentary ."..the beams were extremely stable
during this period and had a very long lifetime."
Yes, but only for about two minutes, then they were dumped because the protection system was acting up. That's a major PITA when running such machines. The protection system is overly sensitive and needs to be carefully tuned to safely detect "safe" conditions and only report minor deviations. Since it has never been run at that energy with beam it it, there are still a few things to sort out, which needs a bit of time (and a certain amount of trial and error). Well, better safe than sorry.
And, by the way. The beams were stable is not what is meant by the term "stable beams". The latter usually refers to the state when they are actually declared stable by LHC operations. When they are declared stable, the experiments can safely turn on their detectors since LHC then guarantees that no beam will go awry and shoot particles into sensitive parts while they are on high voltage. When LHC declares stable beams, this usually means that they are well measured, well positioned and brought to collisions. The "stable" referred to in the blog just means that they were staying in the LHC and not getting into troublesome resonances and scratching collimators and such. (which is a good thing, since beam optics depend on the beam energy, which means LHC was able to keep things under control while ramping, which by the way they did in an amazing short amount of total ramp attempts, which IIRC you can count on one hand)
Actually, the quenches themselves are not the problem, these are quite under control and during the so-called training campaign something that is even deliberately induced.
The problem here is more a chain of unfortunate events, and something that wasn't expected during design.
Basically what happened is:
- faulty electrical connection caused the power supply to trip (i.e. detect some problem and shut down)
- fast discharge was triggered as a consequence
- during fast discharge the current couldn't be handled by the faulty connection, causing an electrical arc
- the arc burnt a hole into the insulation
This is the first thing that hadn't been considered in the design. The cold mass can withstand a very high helium pressure. Helium is not expected to go in the vacuum outside of the insulation (which is there as a thermal shield).
Then, the next problem:
- the electric arc caused some bad electrical fluctuations, causing the quench protection system in several magnets to think there was a quench
- as a consequence, the quench protection heaters then actually induced real quenches
- as a consequence, a lot of Helium got evaporated, causing the Helium pressure in the cold mass to increase sharply
This wouldn't have been a real problem, hadn't there been the hole caused by the arc.
Now the Helium entered the thermal shield around the cold mass with high pressure, causing emergency shutters installed all 107 meters
to close, which are there to protect the vacuum in the rest of the magnets. Unfortunately they were maximally designed to withstand a pressure of regular atmosphere and not the Helium under high pressure. As a consequence they were completely torn by the pressure, causing connections between magnets to be damaged and even more Helium to be released. Several hundreds of meters of tunnel were affected by this, which leads to my personal conclusion that the pressure must have broken several shutters in both directions, until they could finally hold.
So, as a consequence, the actual faulty electrical connection was a small problem compared to the chain reaction which caused in total 29 magnets to be damaged.
(Disclaimer: Personal interpretation of the incident report, there might be flaws in it)
You're missing the point.
He meant free as in speech, not free as in beer.
Netscape didn't cost anything, but it was closed source. At admit it, at that point it also was majorly broken. That's when Netscape was dead and decided to release the source code they started to work on it and it was basically completely rewritten.
A lot of volunteers were involved at that point, resurrecting the beast. It's only when things started to look like something when Netscape jumped onto the bandwagon and put some muscle behind it. But that's different.
Well, does grub work with LVM? Can grub set set command line for *only* the next reboot? (lilo -R)
Two big reasons why I don't use grub. And I personally think that the concept is broken. Filesystem drivers live in the operating system, not the boot loader.
Lilo reads a list of sectors where to find the kernel and initrd and parts of itself, writes them to the disk and tells the boot sector where to find that stuff.
So the boot part of lilo doesn't need to know anything about the filesystem or disk structure, it just loads the stuff and leaves the complicated part to the operating system. And it doesn't write anything into any reserved parts of the disk, just the boot sector.
And I don't need the interactive part of the boot loader anyway, since I can't access the console of that machine, which is, by the way, an AMD64.
lilo has never failed me, and while its concept is simple, it can do a lot, supports every kind of filesystem on weird hard disk / volume configurations. The only thing it could need is a major rewrite, the code has gotten really messy.
Actually, there is something like a backwards compatible API. At least under Linux, I don't know what the other architectures are doing.
::ffff:xxxx:xxxx address range, where xxxx:xxxx is an actual IPv4 address. (also sometimes written as ::ffff:###.###.###.###)
/etc/hosts or address parsing or whatever) and return a list of "addresses". The address can be an IPv4 or IPv6 address, you don't really need to care, just pass the returned information to the socket calls and you have your stream or datagram file handle. Even if the added IPv9 or something else, your application will most likely just work since it doesn't care.
In the IPv6 address space there is the
This means that applications can use the IPv6 sockets API but then use the old IPv4 stack.
This means that a newly written application can use the IPv6 API and still work with the current Internet without the explicit need to support both. A lot of OSS software already supports this.
You can find this in your logs when you have loaded the IPv6 module.
Jul 1 14:35:59 server imapd: LOGIN, user=xxxxxxxx, ip=[::ffff:192.168.xx.x], protocol=IMAP
Also there are some new APIs in the C library that make it easy to write completely (or mostly) protocol-independent software.
Like the "getaddrinfo" library call. It will do a hostname lookup (via DNS,
Most applications are rather easy to port to either the IPv6 API or the protocol independent API. What's more complicated is to port ACL checking and these things because that's where applications start parsing the addresses itself. Or if applications want to store address data or transmit it inside their protocol.
Right.
I'm using PHP on a pre-forking Apache2 now and it's working like a charm.
Actually, PHP could add locking around library calls that are not thread safe. While PHP is easy to use and offers a lot of functionality the PHP code for the extensions is just a big mess design-wise.
That's not an X issue.
I think Owen Taylor is planning to implement this in Pango. It's all but trivial.
That was because reiserfs only hat a writeback journal then. The means that it could happen (very often) that the metadata was written before the actual data was and you would end up with random data in the files that were written just before the crash.
I know it because I had the same problems.
But the current 2.6 kernels have a lot of improvements. reiserfs now also has data=ordered and data=journal journalling modes (with ordered-data being the default now). This means that the actual data is written before the metadata is committed. I've never had those problems again.
And, BTW, it's hardly the fault of the filesystem that you lose some data if your system crashes.
The current reiserfs in 2.6 also has a lot of other improvements. A better block allocator, quota and ACL support. If you need those for 2.4, SUSE has had the patches in their kernels for some time now.
Actually, the plugin does encryption, authentication and compression at once (only the ones that you want, of course).
Well, filesystems are more or less some kind of database.
Especially the Reiser (3/4) filesystems come very close to being a database.
The database is one big tree. You can see it as (in SQL view) like a single table, where the primary key is indexed and the actual data (the objects) can be of different types.
These types are:
The root directory (/) has a known key, where it can be looked up. There you'll find a "directory" item. It contains a list of names, each name also has a key. Using this key you can find the stat data for that file or directory list or the actual file data.
This data can be located anywhere in the tree, even small parts of file content (like the end of files that don't fill up a block so it would be a waste of space to store it in a full block).
Using this approach everything becomes dynamic. And also very fast because if you have a lot of file, you can write all the data into a contiguous region on the disk and don't have to update some fixed positions on the disk.
Now, reiser4 takes this approach to an extreme:
The clue is:
These default plugins make a filesystem from the database. It's just like reiserfs3 now, just faster.
BUT: You can now add plugins if you want. Plugins to store compressed or encrypted files. Plugins to store additional metadata alongside the files. It's basically the file system of the future. Because it's extensible without changing the disk format.
The reiserfs block allocator has some improvements in the latest 2.6-mm kernel.
The main problem with p2p is that the filesystem don't allocate space for the file from the beginning even if the file is shown with its full size in the directory. The blocks are allocated when actual data is written. Since writes occur randomly and only very slowly this is some sort of nightmare for the filesystem.
No, actually the middle floor will have no gravity (geostational orbit).
The top orbit will have "gravity" in exactly the opposite direction because it's spinning faster than than the required speed to stay in orbit. It has to pull on the cable to keep it from falling down.
It is somewhat like going through the earth. As deeper you go the gravity will diminish. In the middle of the earth: None. On the other side the gravity will increase again but in the opposite direction.
The FreeS/Wan ipsec keying daemon is also called Pluto.
More probably there will be problems with bit arithmetics like time 1 or something.
Well, the Matrix Reloaded Trailer also had an official 100Mb version. 1000 Pixel wide, awesome quality.
But I fear that a lost of space was wasted by the quicktime mpeg4 video codec, I recompressed it using the ffmpeg mpeg4 compatible codec, the result was about 70Mb, but without any visible artifacts though it was just recompressed.
I've already posted this in the other thread, there's also an english translation of this (actually several, just modify the url).
Don't forget, there is a public demonstration going on in Strasburg tomorrow in front of the EU Parliament.
Yes, I think a lot of things have been fixed or fixes are underway and mostly working.
And there are also some problems nobody wants to attack...
So it should be: (C+=2,C-2)
Sure. The libraries are basically standard C. The optional thread library has implementations for pthreads and win32 CriticalSections. And there are even some additional compatibility wrappers to make some things more portable (e.g. listing directories).
They are just utility libraries or foundation libraries to build more functionality on top of it. Especially the gobject library is great as a foundation to do modular programs.
In my last project, I used glib from the ground up. I wrote several thousand lines of code before testing it. I made some very aggressive use of glib and gobject. After the code compiled and did not give any runtime warnings anymore it did not contain a single memory leak (verified using valgrind).
glib containts a lot of useful things: lists, trees, hash tables, memory pools, string handling functions and a lot more, everything thread safe.
gobject contains tools on top of glib like "classes" and "objects". It's not the same as in C++ or java, but also very useful. Runtime classes oder data types, generic object properties, reference counting, signal callback, runtime type checking, etc...
The code ist now full of g_... and it took longer than usual because I had to read the documentation, but I think these libraries are very great, and provide a solution for nearly everything that has to do with abstract data types and dynamic memory allocation.
And it's very lightweight, fast and efficient.
What when a game (the best/winning game?) is written in a portable manner. e.g. using standard C/C++ and portable libraries like SDL or OpenGL?
The game would run on Windows, Unix and MacOS(X).
Are the games written for this contest required to be Mac only?
Let's think what this means:
You won't be able to test the programs you're coding.
Does it also mean that sites with javascript need to come up with some form of authorization in order to make it run?
Or, generally, does every scripting language (that is allowed to run) need to check the authorization of the scripts? If it doesn't, you have a potential security breach again...
What about shell scripts, well... "batch files"? Would it be allowed to write some?
Hmmm. To me, this sounds like bullshit. It isn't possible to secure electronic systems. People (not all, but at least some) will always be able to control machines somehow.
Even if you need mod chips. Or even crack the certificate.
it's even in english: http://www.heise.de/english/newsticker/data/jk-31. 05.02-005/