Legalizing drugs makes it economically infeasable for drug dealers to operate. Legalizing all drugs would eliminate drug wars and the violent gangs and drug lords that plague America's cities.
You would not have to worry about methamphetamine labs in your neighborhood. There is no fucking way a small meth lab would be able to compete with a pharmaseutical company's prices and quality.
You really don't want any fucking meth labs exploding in your neighborhood.
The USA has the largest number of convicted drug users in prisons in the world. Legalizing drugs would save millions of dollars in taxes (it costs about $60,000 per year to incarcerate an individual). These people would be humanely treated as addicts, not criminals.
In the 1920's, alcohol was made illegal by Prohibition. The result: Organized Crime. Criminals jumped at the chance to supply the demand for liquor. The streets became battlegrounds. The criminals bought off law enforcement and judges. Adulterated booze blinded and killed people. Civil rights were trampled in the hopeless attempt to keep people from drinking. [lp.org]
Civil liberties suffer. We are all "suspects", subject to random urine tests, highway check points and spying into our personal finances. Your property can be seized without trial, if the police merely claim you got it with drug profits. Doing business with cash makes you a suspect. America is becoming a police state because of the war on drugs. [lp.org]
Also check out http://www.lp.org/issues/relegalize.html
Good question. It will appear in someone's (I believe AA's) tree in a couple months or weeks. From there it will stabilize and get added to 2.6. Here's the latest status update from Hans:
The filesystem is getting reasonably stable. This weekend we hit a bug in space reservation, which we can't reproduce yet but probably isn't too hard to find by code inspection. There is some thought that the assertion not the space reservation is buggy, in any case we'll release a snapshot after it is fixed.
Our performance is generally wonderful and getting better. It has the following weakpoints:
* We allocate a "jnode" per unformatted node in the filesystem. The traversing of these jnodes consumes more CPU than performing the memcpy from user space to kernel space when doing large writes. I don't yet really understand on an intuitive level why this is so, which is a reflection on my ignorance as it is consistent with stories I have heard from other implementors of filesystems who found that eliminating per page structures was an important part of optimizing large writes. We will fix this by creating a new structure called an extent-node that will exist on a per extent basis, and this will probably cure the problem. This will greatly simplify parts of our code for reasons I won't go into, and it will also take us 6 weeks to do it. I don't think users should wait for it, and so we will ship without it.
* Our dbench performance was poor, has improved due to coding changes, and we need to test and analyze again. Perhaps more fixes will be needed, we can't say yet.
* Our fsync performance is poor. We will pay attention to this next year, frankly, after we have fully implemented the transactions API. At that point we will say something like, if you care about fsync performance you should be using the transactions API and/or sponsoring us to tune for NVRAM, users will say back "but our legacy apps on hardware without NVRAM matter!", and we will grudgingly but effectively tune for this because we care about real users too.;-)
Nikita recently invented and implemented a clever bit of code that keeps track of the highest node in the tree that spans a directory, and then performs repeat lookups within the same directory starting from there rather than the root. This is a nice answer to those who keep asking me, wouldn't it be faster to have separate trees for each directory? Now I have better answer for them --- nice work Nikita. It also has the nice side effect of reducing spin lock contention on the root node for 4-way SMP.
I am hoping to move my laptop to SuSE 9.0 running reiser4 sometime this week, and I am hoping we will ask for more outside testers to help us find bugs at that time. While I have mentioned only the performance flaws in this email, our overall performance seems to leave little doubt that the filesystem as-is is far better than V3, and even though it will get much faster with another year or so of tuning, if now we are the fastest available on Linux, we should be shipping now (assuming we find no new bugs in the last round of internal testing).
Benchmarks can be found at www.namesys.com/benchmarks.html
As you can see in those benchmarks, in V4 tails IMPROVE performance due to saving IO transfer time. This is a great improvement over V3, and generally speaking V4 stomps all over V3 performance. It also scales better, has plugins, and improves semantics a little bit (big semantic improvements will be in the next major release not V4). You'll also notice that we increased the size of the fileset to be more fair to ext3, and we tested some ext3 configurations Andrew Morton suggested testing.
Not really goofy, but useful, are those USB adaptors for using console controllers on your PC. You can get a Playstation 2 controller for $7 to $15 bucks at electronics stores, and get the USB adaptor for about $15 online. That's cheap for a nice joystick, and better than the fifty dollar and up PC joysticks since (with PS2 controllers) you get dual analog joysticks, lots of buttons, and vibration motors (supported by windows & linux).
With bayesian filters, more junk mail implies more accurate filtering. If the amount of junk e-mail is reduced by legislation, that could have the side effect of making bayesian filters less accurate and thus getting MORE spam.
Some of us actually want to get as much junk e-mail as possible. Can you figure out why? (Answer in a bit.)
Now, here is a list of advantages this law gives Californians:
they might receive a little bit less spam
Here is a list of disadvantages this law gives Californians:
less freedom on the Internet
increase dependence on lawyers and a busy legal system
precedent to create other laws against of Internet usage patterns
Now, the reason we want junk e-mail is this: we use statistical filters, and the more junk e-mail we get, the better our filters work. By cutting out most junk e-mail, filters have a harder time catching the few junk e-mails that will inevitably be sent.
In the end, if you truly want the fastest system, you should format partitions according to the type of workload they'll be doing. You want fast deletes on a/tmp partition, for example, but you will likely care much more about reading times on your application binaries, and modification times on your data files.
Even though deleting in ext3 takes 87% of the time on R4, the amount of creating, writing, and copying (even on/var/tmp) will outweigh the speed increase from deletion, and when file creation is 3x faster on R4, deletion is moot. Also you have to stat each file before deleting it, and that is 1.5x faster on R4. So unless all you are doing is deleting files, be sure to weigh all the statistics.
None of these advances has to be Reiserfs specific, it's just that they are the few working on them. It's a summary of these developments, so giving examples of some specific scenarios is a good thing to write about.
Now if he was asking about opinions on his article it'd be fine, but he's not, so I'll just discard this as another non-news.
I am asking for a discussion; that's why this is posted here.
Last I heard, Dan Sugalowski said they planned to design Parrot so it could run Scheme code, as well as Python and Ruby, except it wouldn't be able to do continuations (which you need for Scheme). Anyone know more about this?
Also Dan said that Parrot is more suitable for dynamically typed languages like those, while Mono and dot net are better for statically typed, like C# and Java. Anyone know more about that?
Slashdot Mirror
Also check out http://www.lp.org/issues/relegalize.html
Good question. It will appear in someone's (I believe AA's) tree in a couple months or weeks. From there it will stabilize and get added to 2.6. Here's the latest status update from Hans:
The filesystem is getting reasonably stable.
This weekend we hit a bug in space reservation, which we can't reproduce yet but probably isn't too hard to find by code inspection. There is some thought that the assertion not the space reservation is buggy, in any case we'll release a snapshot after it is fixed.
Our performance is generally wonderful and getting better.
It has the following weakpoints:
* We allocate a "jnode" per unformatted node in the filesystem. The traversing of these jnodes consumes more CPU than performing the memcpy from user space to kernel space when doing large writes. I don't yet really understand on an intuitive level why this is so, which is a reflection on my ignorance as it is consistent with stories I have heard from other implementors of filesystems who found that eliminating per page structures was an important part of optimizing large writes. We will fix this by creating a new structure called an extent-node that will exist on a per extent basis, and this will probably cure the problem. This will greatly simplify parts of our code for reasons I won't go into, and it will also take us 6 weeks to do it. I don't think users should wait for it, and so we will ship without it.
* Our dbench performance was poor, has improved due to coding changes, and we need to test and analyze again. Perhaps more fixes will be needed, we can't say yet.
* Our fsync performance is poor. We will pay attention to this next year, frankly, after we have fully implemented the transactions API. At that point we will say something like, if you care about fsync performance you should be using the transactions API and/or sponsoring us to tune for NVRAM, users will say back "but our legacy apps on hardware without NVRAM matter!", and we will grudgingly but effectively tune for this because we care about real users too.;-)
Nikita recently invented and implemented a clever bit of code that keeps track of the highest node in the tree that spans a directory, and then performs repeat lookups within the same directory starting from there rather than the root. This is a nice answer to those who keep asking me, wouldn't it be faster to have separate trees for each directory? Now I have better answer for them --- nice work Nikita. It also has the nice side effect of reducing spin lock contention on the root node for 4-way SMP.
I am hoping to move my laptop to SuSE 9.0 running reiser4 sometime this week, and I am hoping we will ask for more outside testers to help us find bugs at that time. While I have mentioned only the performance flaws in this email, our overall performance seems to leave little doubt that the filesystem as-is is far better than V3, and even though it will get much faster with another year or so of tuning, if now we are the fastest available on Linux, we should be shipping now (assuming we find no new bugs in the last round of internal testing).
Benchmarks can be found at www.namesys.com/benchmarks.html
As you can see in those benchmarks, in V4 tails IMPROVE performance due to saving IO transfer time. This is a great improvement over V3, and generally speaking V4 stomps all over V3 performance. It also scales better, has plugins, and improves semantics a little bit (big semantic improvements will be in the next major release not V4).
You'll also notice that we increased the size of the fileset to be more fair to ext3, and we tested some ext3 configurations Andrew Morton suggested testing.
--
Hans
Try http://www.levelsix.com . They don't have any X-Box though, just PlayStation / N64.
Not really goofy, but useful, are those USB adaptors for using console controllers on your PC. You can get a Playstation 2 controller for $7 to $15 bucks at electronics stores, and get the USB adaptor for about $15 online. That's cheap for a nice joystick, and better than the fifty dollar and up PC joysticks since (with PS2 controllers) you get dual analog joysticks, lots of buttons, and vibration motors (supported by windows & linux).
With bayesian filters, more junk mail implies more accurate filtering. If the amount of junk e-mail is reduced by legislation, that could have the side effect of making bayesian filters less accurate and thus getting MORE spam.
Now, here is a list of advantages this law gives Californians:
Here is a list of disadvantages this law gives Californians:
- less freedom on the Internet
- increase dependence on lawyers and a busy legal system
- precedent to create other laws against of Internet usage patterns
Now, the reason we want junk e-mail is this: we use statistical filters, and the more junk e-mail we get, the better our filters work. By cutting out most junk e-mail, filters have a harder time catching the few junk e-mails that will inevitably be sent.Why stop there? We need as many languages as we can get, especially in today's economy and job market.
Unfortunately none of those is set by default. They could be a great "selling" point for Mozilla.
I always set
" , true);e .close", true);e .directo ries", true);e .locatio n", true);e .menubar ", true);e .minimiz able", true);e .persona lbar", true);e .resizab le", true);e .scrollb ars", true);e .status" , true);e .titleba r", true);e .toolbar ", true);g e", true);w ", true)
user_pref("dom.disable_window_flip", true);
user_pref("dom.disable_window_move_resize
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_open_featur
user_pref("dom.disable_window_status_chan
user_pref("browser.block.target_new_windo
to keep crappy web pages from disabling my menus.
Good question, that infinite recursion is avoided :)
None of these advances has to be Reiserfs specific, it's just that they are the few working on them. It's a summary of these developments, so giving examples of some specific scenarios is a good thing to write about.
Now if he was asking about opinions on his article it'd be fine, but he's not, so I'll just discard this as another non-news.
I am asking for a discussion; that's why this is posted here.
XML sucks because of attributes. I can have a and a thing and they are treated differently. How pointless that is.
Plus any drooling idiot can come up with a way to represent a tree in a file. They did that 100 years ago with Lisp.
Awesome!
Last I heard, Dan Sugalowski said they planned to design Parrot so it could run Scheme code, as well as Python and Ruby, except it wouldn't be able to do continuations (which you need for Scheme). Anyone know more about this?
Also Dan said that Parrot is more suitable for dynamically typed languages like those, while Mono and dot net are better for statically typed, like C# and Java. Anyone know more about that?