Thanks for the informative post. The law is simply too complicated these days. Here's the text he linked to:
Talking about a "War Powers Act": Nasir v. Anderson (D NJ unpub 8/25/97); Daigle v. US (6th Cir unpub 1/29/96) 76 F2d 378(t); McCann v. Greenway (WD Mo 1997) 952 F.Supp 647; this
myth is especially popular with a veterinarian, Gene Schroder, (sometimes spelled Schroeder, but I follow the spelling used in 800 P2d 1360), who evidently characterizes as the "War Powers
Act" the National Banking Emergency Act of March 9, 1933, the first act signed by FDR, 48 Stat 1, which was mostly codified under title 12 (banking) and deals entirely with regulating banks
and restricting the hoarding and exporting of currency and precious metals, contrary to various myths it has nothing to do with the flag, the military, the courts, or ordinary life; the statute
apparently did not, by itself, commence a National Emergency and, if it did, that period was long over. A court decision, US v. Bishop (10th Cir 1977) 555 F2d 771, held that a Vietnam War
perp's destruction of a power line in 1969 could not be especially punished under the Sabotage Act as having been committed during a time "of national emergency" as the only national
emergency that could be argued was still in effect in 1969 was Truman's 1950 Proclamation arising from the Korean War. Almost immediately after the Bishop decision, Congress authorized a
study into emergency powers legislation preparatory to new legislation to restrict the applications of states of emergency; the resulting study, the Report of the Senate Special Committee on the
Termination of the National Emergency, Emergency Powers Statutes: Provision of federal law now in effect delegating to the executive extraordinary authority in time of national emergency,
Sen.Rept. 93-549, 11/19/73, 607 pages; mostly a listing of statutory provisions that allowed the govt to skip certain procedural steps if during a declared state of national emergency. This report
determined that, in 1973, there were still existent four declared states of emergency: Section 1 of the 1933 Act, which is (still in effect) now 12 USC sec. 95b (which only authorizes the
issuance of new regs designed to facilitate 12 USC sec. 95a which restricts the exporting, hoarding, or melting of gold and other precious metals), Truman's 1950 proclamation about the Korean
War, Nixon's 1970 proclamation about the postal service strike, and Nixon's 1971 proclamation about an economic emergency arising from the balance of trade deficit which including imposing
an additional tariff on imports. As a result of this study, Congress enacted a few years later the National Emergencies Act, PL 94-412, 9/14/1976, 90 Stat 1255, codified at 50 USC sec. 1601,
1621, etc., which imposed a two year duration on any existing national emergencies and required that any future declaration of a national emergency must be reviewed by Congress at six month
intervals. Subsequently, Congress amended the 1933 Act by enacting the War or National Emergency Act, PL 95-223, 12/28/77, 91 Stat 1625, which amended 12 USC sec. 95a to limit explicitly
the President's capacity to impose the restrictions of the Trading with the Enemy Act and to issue regulations about international transactions involving money, credit or precious metals to
"time of war" and not during a mere "period of national emergency" (striking that expression wherever it had appeared in the 1933 Act); in the accompanying committee report (Sen.Rpt.
95-466) it was explained that this 1977 law was in furtherance of the 1976 law on limiting national emergencies, and was deliberately intended to limit and terminate what it considered
excessive Presidential use of the four old declared emergencies to manipulate the laws on international financial transactions. Altho militia mythology stresses that we are always in a declared
state of emergency, it turns out that the emergency situations which still persist - and they do persist, according to occasional Presidential Executive Orders - relate directly to foreign events,
such as Mideast terrorism, and are limited to such things as embargoes and the freezing of certain bank assets associated with a foreign adversary.
... I have a question for you, though; why do executive orders reference previous executive orders about the "emergency," extend it, and also reference section 5b of Title 50? The 1976 law did not repeal Title 50, or end all of the "emergencies" declared under its aegis, or nullify the executive orders that are based on it. Granted that congress requires renewal of the emergencies now, but it's always renewed. The end result if the same -- sweeping power for the President.
Do you have a list of all current national ermegencies you can post for us? Perhaps with references to EOs that mention them?
It's the national emergency that lets the President legislate via executive order. The power of legislation is supposed to rest in congress, not the President. Since 1933, the President has been able to legislate on his own without oversight from any part of the government. We have been living in a nation of Public Policy, not Common Law, since then.
Ask your favorite candidate if they plan to end all national emergencies, including the big, old one.
(previous post due to slipup with "submit" vs "preview")
Well, be have been declared the enemy since,a href="http://www.unitedstates-on-line.com/FDR32.ht ml">1933, when Franklin Delano Roosevelt declared a number of national emergencies (banking, agriculture, etc) as part of his New Deal program and obtained sweeping, dictatorial powers under the Title 50, also known as the War Powers Act of 1917. Section 5b provides for expanded presidential powers. This act has been amended several times. We're still in that state of emergency, officially. FDR didn't assign the new powers to existing agencies, but created new "temporary" agencies, many of which still exist today. No president has been willing to end it, because they give up their special powers when that happens.
Can we at least get the same information and correlations for all officers of the government posted online? After all, if they think it's fine to correlate and snoop on us, it must be okay for use to correlate and snoop on them.
Or they could have kept their promise not to hand out the census data. Yeah. Right.
The Boorz article mentions that the citizens of Galviston County, TX voted themselves out of the Social Security System. I gotta get me some of that. I'd take my instant 15% "raise" and put it straight into certificates of deposit.
by Anonymous Coward on 02:41 PM October 22nd, 2000 EST (#223)
I have been programming all of 2000 without a debugger because we are bringing up an operating system on IA64. We have a complete printk() equivalent that helps us tremendously. I fixed some problems single-stepping IA64 instructions with our own-made disassembler.
Does this make me a superior being ? Nope it only makes me wish for a debugger. We would still keep our invaluable printk()'s as they still allow us to get useful info when no debugger is attached.
Having a debugger available will not make me program sloppily. We do test our code thorougly, comment it and have automated quality metrics. But even with those you will always get a nasty bug and then a debugger can save your day,week or month.
You are a complete loser and I have no respect for people with your attitude. They do not deserve programming jobs. I hope you did not represent accurately the thoughts of the Linux kernel leaders. I fear you did.
Just quoting you so you can use my +1, so that someone will read this. What OS, by the way?
It contains a LOT of USB-fixes (I've checked it out.)
Yes. It doesn't oops anymore, but it doesn't work, either. The driver hangs unti la reboot, but doesn't actually oops anymore. I think I did submit one oops report to someone, but I can't remember. When I get a crash I can't attribute to my own stupidity and/or hardware problems, I generally report it, unless I know that it's already being worked on.
The difference between test6 and test10pre3 is quite amazing. test10pre4, to be honest, isn't very good however,
I decided to just sit it out until the first production release, and then get involved with the Linux port again, and submit patches for 2.5 (including real unicode support, VFS enhancements and a new filsystem).
As for the off-list posting with you being put in Alan's killfile, this sounds a little strange. I can well imagine you being put in Viro's killfile, however; he's quite easy to irritate sometimes. You might well have been blocked out by Alan's VERY aggresive spamfilter,
Viro is easy to incite. He's like one bug button, and people keep pressing it. Alsn actually emailed me that people discussing streams earned a place in his killfile. But I later sumbitted the printk patch for 2.2.18, and was told "nope" when I asked if it could be included. No explanation.
it's simply a fact that non-native filesystems ARE less important to support than native ones. And thus we can allow ourselves to leave the planning of that support to the future and focus on the more urgent issues instead.
We were discussing streams in terms of changes to the 2.5 kernel. And just because they're not the default filesystem doesn't mean they're not useful or important. If you want a Linus server to really be able to replace an NT one, you'll need streams and ACLs.
I think it'll turn out good; after all, it forced Viro to make his VFS-changes earlier than planned.
That's as may be; but it created more chaos in the short-term, and undermined Viro's delegated authority. ANd got Linus back into the position of accepting/rejecting patches. That act violated any semblance of organizational structure there was. I understand it's his, but it's easier to get work done with help, and it's easier to get and keep help if your earn their respect.
Please submit your proposals for streams/EA's again to the kernellist. But do as soon as v2.5.0 is released, or at least AFTER v2.4.1 has been released.
This is my plan.
Actually, no. I think you'd complain + use FreeBSD. Quite like what you're doing right now. However, I'm glad to hear this is not the case...
Well, I've not given up on Linux totally, and still use it for my home and work desktops, and the cvs server, mail server, web server, etc. I've also not given up on the Linux port of the FS we're developing -- just decided that it's not possible in the short term due to internal Linux fuckage (which may be -- hopefully will be -- fixed in 2.4/2.5). Since I still have to complete development of the filesystem, I'm doing it on FreeBSD now, because it's stable and provides the features we need.
I got that idea, too -- that Sony won't open it, but if we take away the need for their NDA, then they might.
I would say that it's okay in this case. It's like dropping a wrench in the machine in a totalitarian state -- you can't be totally free at the moment, but you can fuck up the totalitarianism a little. That's a morally justified choice.
You can't possibly believe that Linux is the only operatingsystem that has got buggy device-drivers. Device-drivers ARE fully capable of crashing your machine.
Oh, I know. QNX and Multics are the only OSes I know that can survice a driver crash. The scanner would opps the kernel without the scanner driver being loaded. It was just the usb-uhci code oopsing, before I even had the scanner.o compiled. It works fine on my home machine, as long as I don't turn off the scanner while it's in operation (otherwise... oops).
What's so broken about the semaphores/spinlocks in the v2.4 kernel?
To be honest, I dropped the 2.4 kernel after test-6 and retreated to 2.2.16 and 17, which were also broken (race conditions, oopsing on upping the sempahore). Now we're doing FreeBSD, as I cannot lose more time waiting for things to be fixed.
But imho, none of the proposals [streams/EAs] posted on the LKML during the entire debate was sane either.
Ours was posted off-list, by invitation from Viro and Cox. Since they simply told us to shut up and added us to their killfiles, we dropped it. I'll post our proposal to the list if you'd like.
But face it, NTFS, HFS and BeFS will never be the native filesystems on a Linux-machine.
I don't think anyone ever suggested that; just they they exist and Linux should be capable of supporting them. Interoperability.
I'm pretty confident Alan must have given you an explanation why [he rejected the prink patch]?
He did not.
It should print long long's without any trouble, at least in the v2.4-series.
That's our patch, I think. It was accepted for 2.4, but not for 2.2. Because 2.2 is the 'stable' kernel, a working printk is useful now The 2.4 will be nice when that kernel stabilizes (in terns of interfaces).
No, Linus doesn't have to accept code he doesn't like, but if you try to imagine how much code he has to accept every week,
It's silly for Linus to have to look over every patch. That's what I'm talking about -- a lack of guidelines, coding standards, etc. means that delegation doesn't happen. Viro's nominally in charge of filesystems, but that doesn't stop Linus from tossing in new ones (DevFS, JFFS). There's no clear control. If there was -- if the kernel had clear areas of responsiblity, that is, if it were modular, then Linus would not have to even look at patches for systems he had delegated.
He does a DAMN good job, though
So does Alan Greenspan, but central planning still has its limits.
People who don't realise that they can't patch
their own kernel to add the kernel debugger
It's more that, because good support for debuggers is kept out of the kernel, applying one of the kdb patches doesn't help as much as it should. We've tried them all.:) Some of them actually make the kernel crash. Others don't provide needed information -- like a stack dump.
However, I believe he will sooner or later begin using BitKeeper. Maybe already for v2.5
That would rock!
But you have to realise, that it's impossible to work 48 hours/day.
Viro is notorious for making changes without warning and then not documenting them. It's hit or miss with everyone else. And I'm not expecting people to work 48 hours a day; I'm saying, if you don't have time to do it right the first time, do you have time to fix it later?
you'd probably not appreciate the kernel no matter what changes are made.
Not true. If I simply hated Linux and didn't care if it improved, I would simply have kept my mouth shut and used FreeBSD, or something. THe fact is, I want it to improve. I like it. I'm not blinded to its faults, though.
The reason I considered your post trolling wasn't because of your opinions on Linux, but because you implied that people reading Slashdot automatically would flame you, send spam to you, direct ICBM's at your house etc., just because you have a different opinion.
Only because it's happened in the past. The voice of experience and all. I figured that if I pointed out in my message that that type of response isn't constructive, it would prevent that type of response. It has worked so far, for the most part. Lots of people start of posts of controversial opinions with "this isn't a flame; don't flame me."
Thanks! I'm glad someone is willing to debate the ideas I presented, and not my spelling, shoe size, etc.:)
The mantra 'modular gooood - spaghetti baaad' is too simplistic
It certainly is -- as is any type of fanaticism or dogma.
However, spaghetti code does have one virtue: it is often faster.
Even NT, which is very modular, compromised with the "fast path" i/o machanism. However, they started from a position of modularity, and added a hack. Linux is the other way around. We won't discuss win32, because it's utter crap. When I say nice things about NT, it's only about the David Cutler kernel.
the code produced by the other types of programmers - who heavily require debuggers - is sloppy and the result of confused thinking.
I'm not disputing that; it's true. However, engaging in social engineering rather than simply rejecting patches is silly and counter-productive. Even very good programmers can and do use a debugger productively. Bad code is bad, regardless of whether a debugger was used. Providing a debugger won't make a good programmer bad, and withholding one won't make a bad programmer good. It would be better to provide coding standards and/or guidelines and recommended testing procedures, and allow a debugger, than to simply disallow a useful tool because it can fall into the wrong hands. If there were standards and even plans, then a lot of patches could be rejected because they don't meet the standards, rather than "Linus doesn't like it." And there would probably be fewer bad or useless patches if there was a plan and guidelines, because people would know from the outset what is expected. Take that one step further, and provide some public coordination and documentation of efforts, and I think it would be better still.
Let me suggest that you attempt to create your own kernel based on your ideas of what a kernel ought to be. If you are right everyone will be able to see that it is so.
This is correct, and I've been considering forking the kernel with the aid of the big outside players (IBM, SGI, etc.) and starting an Advanced Linux Kernel Project. Based on the reasion I've gotten to my post via email,/. replies and personal communication from my friends and co-workers, people want it to happen. Setting up the political structure will take some time. Want to help?
he OOM-killer (at least as of test10pre3) does NOT kill kswapd or X11, unless those really ARE the villains.
I cannot think of a single acceptable reason for the OOM code to kill kswapd. That's like the kernel wiping its nose with a revolver.
Because if kswapd, a kernel-thread, is buggy, your system will die anyway. But it isn't, and it won't get killed.
Kswapd regularly dies on my 2.2.16 + USB machine. 2.2.16 is supposed to be a stable kernel -- release 16 of a stable kernel. I can oops the kernel by merely plugging in my scanner to the USB port. Yay.
But the VFS in Linux is not very hard to write a filesystem for,
A simple one, no. One that must make use of the broken spinlocks and semaphores, while avoiding the wrath of bdflush and kupdated, is very hard to stabilize on Linux. There are many unintended consequences that pop up due to the spaghetti.
ReiserFS wasn't working properly
True, but interesting that it was stated during the 2.3 series that Ext3 would probably be included in the 2.4 kernel, even though it was less capable, less stable, and in less widespread use than ReiserFS at the time.
This isn't about narrow-mindedness, it's about sanity and interoperability. It's about not making the same mistakes Microsoft keep doing over and over again. NTFS streams ARE a complete mess. Try to map them sanely into the Unix-world, and you'll see. Try to use tar to backup an NTFS-volume and see how much you'll preserve...
I.e., they're not Posix. As I was saying. Linus and I were arguing that, whether streams are posix or not is irrelevant, because there are many existing filesystems that people want and need to use from within Linux that use streams and/or EAs, and Linux would do well to provide clean support for them. Like you said, to provide interoperability and sanity. No one will accuse the current HFS method of posixizing a streams-capable filesystem of being sane. The notion of providing a way to support filesystem that provide streams/EAs was met with a quite visceral reaction from Viro, Tso and especially Cox. How do you plan to support all the features of NTFS, XFS, BeFS, HFS and HPFS on a VFS that respects only Posix? And incidentally, the tar format supports extended attributes, even though the current tar tools do not. Pax also supports extended attributes. If interoperability was actually the goal, then there would have been a discussion of how to provide support for streams without breaking the semantics of filesystems that don't support them. We even submitted a thought-out suggestion for namespace augmentation that would provide the needed support and compatibility for Posix filesystems. Victim of the killfile.
Oh, and about kernel-debuggers. Yes, Linus is violently opposed to those. But does that prevent YOU, or anyone else for that matter, from using one?
Yes. His refusal to allow support for KDBs means that they do not work well, or at all; unlike the kdbs of other OSes. "Oops" is not useful output in a lot of situations, noteably race conditions. I imgine there would be fewer race conditions inhernent to the kernel if there was a built in debugger, and there would be less code with undefined behavior if there was a debugger, and developers would be able to get a meaningful stack trace when their driver crashes if there was a debugger. What gooed does printk do when the kernel resets precipitously and cannot flush its output? Stating at the sudden appearance of the bios screen isn't helpful.
Pray tell me, if you don't want the kernel-developers to tell you to fork your own kernel, and you don't want to submit changes to the kernel to clean things up because you don't like the development process, why DO you worry?
We do submit things. Cox even rejected a patch to provide 64-bit printk output on 32-bit platforms, twice. This, after developers are told they should use printk and not a debugger. Never mind that even printk is lacking.
...assignments for different CS-classes simply having the bugs patched over by if-clauses, from people that have traced the code to see where it fails
Yeah... it really kept all the a[i]=i++ code out. And Linus doesn't have to accept code if he doesn't like it; why cripple the use of a debugger for the people would would actually make good use of it? The 1-st year CS students won't write worthy code whether or not they use a debugger, so why stop them? Unless it's just social engineering.
v2.3-series has been spent rewriting the VFS and the Network layer to be clean,
Not to mention the 2.4-test-pre-whatever series, which has also been spent rewriting the VM and VFS. Linus should never have attempted to force things by jumping the version number up. It didn't work, and merely caused a lot of frustration for a lot of people. Relabelling the kernel as "ready" didn't make it ready.
It is VERY unlikely that people are uninterested in the v2.4test kernels because they've lost their faith in the kernel development process. Why? Simple. Because most people that don't hang around on LKML or Slashdot don't even know about how the development process works. For that matter, most people hanging on/. probably don't.
They do see all the delay announcements. They see the kernel not being released in two years. They see features being backported so that Linux can just keep up. Who will believe that the 2.4 kernel is ready when they finally announce it? They've announced 10 versions of 2.4 already, and none of them are production quality.
And, why won't Linus use CVS? Accidental additions can be backed out, the commit logs with provide a start for documentation (since the inner circle of kernel developers themselves don't write any), and it will allow better control of the process at large. Right now, all the major decisions are made off list between Viro, Cox, Linus, etc. and the rest of us get to hear about them only the next patch is released. There is never and intent or direction advertised before, and there's no documentation after. If they at least used CVS and let people read the histories, we would have a better idea of what few design decisions are made actually mean.
You know, you ARE really trolling.
That same comment is made any time any criticism is made of any aspect of Linux. It's lost its sting.
At least those DOS and Windows 1.0 apps will still run on Win98/NT
Actually, most Windows 1.0 apps won't run right, even on Windwos 3.1, and a lot of DOS apps will not run right either, if at all. In fact, the dos version of warcraft will reliably hang NT, even from a non-privildged account, just by being executed.
Most of the redhat releases were actually both binary and source compatible. Can't say that for even revisions of the same release of Windows.
I don't collect karma anymore. My karma did not rise because of the points allocated to my post by moderators. In fact, it got lower because of one "overrated" moderation.
Oh, and I've posted this as an AC
Coward.
You're the prefect example of the useless LKML/Slashdot knee-jerk closemindedness that's been so prevalent recently.
DOS -> windows 1.0 -> 2.0 -> 3.0 -> 3.1 -> windows 95 -> windows 95 osr1 -> windows 95 osr 2 -> windows 98 -> windows 98 SE -> windows ME. Also, OS/2->OS/3->NT3.1->NT 3.5 -> NT 3.5.1-> NT 4.0 -> SP1->6-> NT 5.0 (win 2k) -> datacenter, server, professional, embedded. And don't forget wince. There's actually more versions of windows than Linux at the moment.
I'd like to know why people aren't interested in 2.4. Is it that it's been delayed so long it's like vaporware?
I'd say that the reason that people aren't interested in the 2.4 kernel is they they have lost faith in the development process.
Over the last two years, people have repeatedly posted
on the LKML in one way or another that the emperor has
no clothes. They've been nice, they've been rude,
they've even posted good ideas and patches to provide
some clothes. But, universally, the response from the
LKML acolytes has been a variant of "the emperor isn't
naked; he is in fact wearing a 3-piece suit, and if
you don't like it, you can get your own emperor, you
idiot."
It's very sad. Criticism is what keeps any public
enterprise honest and productive, and the denizens of the LKML don't have any tolerance for it.
The linux development process has little direction, no
planning, little to no leadership, meaningless feature
freezes, and little to no documentation and
guidelines. The kernel itself *is* spaghetti code
inside, no matter what people say. They try to maintain control over what people use by not exporting some functions from the kernel.o files, but that's a bandaid, and a way to control who gets to work with the kernel more than what can be done with it. That the kernel is spaghetti code is one of the major reasons that 2.4 is so late, and so buggy. Just try to do some
kernel programming, and you'll see, if you don't believe me. Take a look at the
big, ugly union in the VFS. Figure out all the places that bdflush gets invoked, and the number of different ways to have a pinned buffer flushed by other parts of the kernel anyway. Look at the brokenness in
the spinlocks and semaphores. Look at all the VM
rewrites and the warring but both broken USB stacks.
Check out the tendency of the VM OOM "feature" to kill random programs like X and
kswapd. And don't forget all the race conditions.
It
is very difficult to alter some part of Linux because
of all the unintended consequences. It's difficult to get needed features and clean-ups into the kernel because of cronyism and a narrow-minded religious devotion to Posix. Go back and read up on the
NTFS-streams thread for a good example of that (Alan and Viro actually invited everyone talking about streams to an off-list discussion, and then notified them that they had been added to their killfiles).
Clean code? Just look at the
2.4.0-test-pre-pooch-screw series of debacles, where
the VM is rewritten every few weeks, and new features
are tossed in while there's still massive bugs to fix
in the code that's already there, and in spite of repeated "feature freezes". That would all be fine in a 2.3.x series kernel, but judging from the version number, "2.4.0-test" is supposed to be pretty stable except for bug fixes -- not have major features added and subsystems being rewritten.
Linux has terminal featureitis. No one wants to work
on the hard things; they just want to add features.
Quickly.
And Linus, to make things worse, claims that a kernel
debugger is counter-productive; that debugging with
printk puts hair on your chest. Never mind that you
can't debug race conditions well, if at all, by adding
printk statements everywhere, because they change the timing of the code
when it runs. Never mind that essentially every other
'modern' OS includes a kernel debugger, and that many
of those OSes are better designed, better implemented,
and perform better and run more reliably than Linux
(FreeBSD, HPUX, Solaris, and even NT come to mind).
defer any further feature creep until the next
release
concentrate on fixing bugs in the pre-release cycle
aim for modularity, stable interfaces and good
documentation to make upgrades and new feature
addition easier and the learning curve less steep
provide robust methods for troubleshooting the
system to make development and debugging easier.
Linux does none of these things. By design.
So continue to kvetch about idiots like me (and IBM,
and SGI, and HP, and Reiser, and about 1000 other
people and companies) pointing out that Linux is
fundamentally screwed.
The most common response to criticism is a variant of "love it or leave it."
Keep suggesting that we go
write our own damn OS if we don't like it;
your love it or leave it response will be accepted one
day, and we will leave Linux. I actually think it
would be a good idea for the major external linux
players to fork the kernel, clean it up, and maintain
their own version. I don't doubt that it would shortly
become the defacto standard kernel, because it will be
cleaner, more stable, more scalable, more extendible,
and will probably be released on time and respect
feature freezes. SGI, IBM, Reiser and a lot of other
people and companies have a lot of good code and ideas
to contribute, not to mention full-time developers,
years of experience making scalable and robust
systems, and a willingness to release all that work
under the GPL. And if they fork the kernel, they can do it without having to be named "Ted", "Ingo", "Alan", "Linus" or "Rik".
One day the question will be, are *you* relevant? Why
should we accept *your* code? Is it clean? Is it modular? Is it safe (see LWN article about C code with undefined behavior being included in the kernel). Of course, a fork can always be re-merged with the holy penguin pee version. In the meantime, all the people who want to run Linux on enterprise systems rather than PDAs and webpads can have a stable, working kernel with adequate features.
It would be useful if people would make substantive
replies to this message, rather than engage in the
usual comments about rioting, sending spam reports,
saying "love it or leave it," moderating it as a troll, port-scanning my mail server, attempted hacks and other juvenile/illegal acts, sending spam reports, threatening violence, etc. Of course,
substantive debate is really hard to come by on either the
LKML or Slashdot, so I don't expect it. So, go ahead, get started
telling me to sod off. I'll get back to switching over to FreeBSD, although I would prefer if someone would take up a rational refutation of this message instead. Show me the Emperor's Clothes.
Our Anonymous Coward friend has, in fact, made it abundantly clear that he doesn't want freedom; he wants free stuff. AC For President! He will make us his slaves, but feed us.
________________________________________
Re:Libertarianism the new Republicism bur more evi
on
Should You Vote?
·
· Score: 2
The guy making 15k is going to pay 1.5k in taxes.
Not true. All of the flat tax plans call for a flat tax on all income over a certain amount, and it's typically fairly high, like $60,000. Your $15k/year example guy would pay no taxes.
________________________________________
Re:Libertarianism the new Republicism bur more evi
on
Should You Vote?
·
· Score: 2
why cant we accept paying political campaigns to remove corporate influence.
he will only help empower the already over-powered multinationals.
Not true. Libertarian government would kick coporations off of the public teat and make them accountable for fraud.
It would be cool if the corporate death penalty were revived as well.
________________________________________
Re:This is not the election......
on
Should You Vote?
·
· Score: 2
If your the backbone of the democratic party with weak convictions been like the parent post.
... I have no idea what that means.
________________________________________
Re:Libertarianism the new Republicism bur more evi
on
Should You Vote?
·
· Score: 2
I love this strict almost fundamentalist Constitution talk, ever hear of amendments?
"fundamentalist Constitution talk"? The Consitution is the Supreme Law of the Land. Pointing out that the government is in violation of the supreme law of the land isn't "fundamentalism." It's not hard to understand the meaning of words like "shall make no law," "shall not be abridged," and "reserved to the states and people". What good is a supreme law of the land if it's not actually followed?
Or those part of the evil empire also?
No, they're part of the system. The idea is that, when large changes are made to the supreme law of the land, there must be vast support for it. As opposed to simply issuing an executive order.
Slashdot Mirror
Thanks for the informative post. The law is simply too complicated these days. Here's the text he linked to:
Do you have a list of all current national ermegencies you can post for us? Perhaps with references to EOs that mention them?
Thanks!
________________________________________
Forget not the fact that the geezers vote en masse, no smart politician wants to get them angry(Or scared).
Oh, I realize it. I just wish everyone did.
________________________________________
Well, be have been declared the enemy since 1933, when Franklin Delano Roosevelt declared a number of national emergencies (banking, agriculture, etc) as part of his New Deal program and obtained sweeping, dictato ria l powers under Title 50, also known as the War Powers Act of 1917. Section 5b provides for expanded presidential powers. This act has been amended several times. We're still in that state of emergency, officially; in fact, Clinton extended it. FDR didn't assign the new powers to existing agencies, but created new "temporary" agencies, many of which still exist today. No president has been willing to end it, because they give up their special powers when that happens.
It's the national emergency that lets the President legislate via executive order. The power of legislation is supposed to rest in congress, not the President. Since 1933, the President has been able to legislate on his own without oversight from any part of the government. We have been living in a nation of Public Policy, not Common Law, since then.
Ask your favorite candidate if they plan to end all national emergencies, including the big, old one.
(previous post due to slipup with "submit" vs "preview")
________________________________________
Well, be have been declared the enemy since ,a href="http://www.unitedstates-on-line.com/FDR32.ht ml">1933, when Franklin Delano Roosevelt declared a number of national emergencies (banking, agriculture, etc) as part of his New Deal program and obtained sweeping, dictatorial powers under the Title 50, also known as the War Powers Act of 1917. Section 5b provides for expanded presidential powers. This act has been amended several times. We're still in that state of emergency, officially. FDR didn't assign the new powers to existing agencies, but created new "temporary" agencies, many of which still exist today. No president has been willing to end it, because they give up their special powers when that happens.
________________________________________
Can we at least get the same information and correlations for all officers of the government posted online? After all, if they think it's fine to correlate and snoop on us, it must be okay for use to correlate and snoop on them.
Or they could have kept their promise not to hand out the census data. Yeah. Right.
________________________________________
The Boorz article mentions that the citizens of Galviston County, TX voted themselves out of the Social Security System. I gotta get me some of that. I'd take my instant 15% "raise" and put it straight into certificates of deposit.
Anyone have any details on how to get out?
________________________________________
by Anonymous Coward on 02:41 PM October 22nd, 2000 EST (#223)
I have been programming all of 2000 without a debugger because we are bringing up an operating system on IA64. We have a complete printk() equivalent that helps us tremendously. I fixed some problems single-stepping IA64 instructions with our own-made disassembler.
Does this make me a superior being ? Nope it only makes me wish for a debugger. We would still keep our invaluable printk()'s as they still allow us to get useful info when no debugger is attached.
Having a debugger available will not make me program sloppily. We do test our code thorougly, comment it and have automated quality metrics. But even with those you will always get a nasty bug and then a debugger can save your day,week or month.
You are a complete loser and I have no respect for people with your attitude. They do not deserve programming jobs. I hope you did not represent accurately the thoughts of the Linux kernel leaders. I fear you did.
Just quoting you so you can use my +1, so that someone will read this. What OS, by the way?
________________________________________
It contains a LOT of USB-fixes (I've checked it out.)
Yes. It doesn't oops anymore, but it doesn't work, either. The driver hangs unti la reboot, but doesn't actually oops anymore. I think I did submit one oops report to someone, but I can't remember. When I get a crash I can't attribute to my own stupidity and/or hardware problems, I generally report it, unless I know that it's already being worked on.
The difference between test6 and test10pre3 is quite amazing. test10pre4, to be honest, isn't very good however,
I decided to just sit it out until the first production release, and then get involved with the Linux port again, and submit patches for 2.5 (including real unicode support, VFS enhancements and a new filsystem).
As for the off-list posting with you being put in Alan's killfile, this sounds a little strange. I can well imagine you being put in Viro's killfile, however; he's quite easy to irritate sometimes. You might well have been blocked out by Alan's VERY aggresive spamfilter,
Viro is easy to incite. He's like one bug button, and people keep pressing it. Alsn actually emailed me that people discussing streams earned a place in his killfile. But I later sumbitted the printk patch for 2.2.18, and was told "nope" when I asked if it could be included. No explanation.
it's simply a fact that non-native filesystems ARE less important to support than native ones. And thus we can allow ourselves to leave the planning of that support to the future and focus on the more urgent issues instead.
We were discussing streams in terms of changes to the 2.5 kernel. And just because they're not the default filesystem doesn't mean they're not useful or important. If you want a Linus server to really be able to replace an NT one, you'll need streams and ACLs.
I think it'll turn out good; after all, it forced Viro to make his VFS-changes earlier than planned.
That's as may be; but it created more chaos in the short-term, and undermined Viro's delegated authority. ANd got Linus back into the position of accepting/rejecting patches. That act violated any semblance of organizational structure there was. I understand it's his, but it's easier to get work done with help, and it's easier to get and keep help if your earn their respect.
Please submit your proposals for streams/EA's again to the kernellist. But do as soon as v2.5.0 is released, or at least AFTER v2.4.1 has been released.
This is my plan.
Actually, no. I think you'd complain + use FreeBSD. Quite like what you're doing right now. However, I'm glad to hear this is not the case...
Well, I've not given up on Linux totally, and still use it for my home and work desktops, and the cvs server, mail server, web server, etc. I've also not given up on the Linux port of the FS we're developing -- just decided that it's not possible in the short term due to internal Linux fuckage (which may be -- hopefully will be -- fixed in 2.4/2.5). Since I still have to complete development of the filesystem, I'm doing it on FreeBSD now, because it's stable and provides the features we need.
________________________________________
I got that idea, too -- that Sony won't open it, but if we take away the need for their NDA, then they might.
I would say that it's okay in this case. It's like dropping a wrench in the machine in a totalitarian state -- you can't be totally free at the moment, but you can fuck up the totalitarianism a little. That's a morally justified choice.
________________________________________
You can't possibly believe that Linux is the only operatingsystem that has got buggy device-drivers. Device-drivers ARE fully capable of crashing your machine.
:) Some of them actually make the kernel crash. Others don't provide needed information -- like a stack dump.
:)
Oh, I know. QNX and Multics are the only OSes I know that can survice a driver crash. The scanner would opps the kernel without the scanner driver being loaded. It was just the usb-uhci code oopsing, before I even had the scanner.o compiled. It works fine on my home machine, as long as I don't turn off the scanner while it's in operation (otherwise... oops).
What's so broken about the semaphores/spinlocks in the v2.4 kernel?
To be honest, I dropped the 2.4 kernel after test-6 and retreated to 2.2.16 and 17, which were also broken (race conditions, oopsing on upping the sempahore). Now we're doing FreeBSD, as I cannot lose more time waiting for things to be fixed.
But imho, none of the proposals [streams/EAs] posted on the LKML during the entire debate was sane either.
Ours was posted off-list, by invitation from Viro and Cox. Since they simply told us to shut up and added us to their killfiles, we dropped it. I'll post our proposal to the list if you'd like.
But face it, NTFS, HFS and BeFS will never be the native filesystems on a Linux-machine.
I don't think anyone ever suggested that; just they they exist and Linux should be capable of supporting them. Interoperability.
I'm pretty confident Alan must have given you an explanation why [he rejected the prink patch]?
He did not.
It should print long long's without any trouble, at least in the v2.4-series.
That's our patch, I think. It was accepted for 2.4, but not for 2.2. Because 2.2 is the 'stable' kernel, a working printk is useful now The 2.4 will be nice when that kernel stabilizes (in terns of interfaces).
No, Linus doesn't have to accept code he doesn't like, but if you try to imagine how much code he has to accept every week,
It's silly for Linus to have to look over every patch. That's what I'm talking about -- a lack of guidelines, coding standards, etc. means that delegation doesn't happen. Viro's nominally in charge of filesystems, but that doesn't stop Linus from tossing in new ones (DevFS, JFFS). There's no clear control. If there was -- if the kernel had clear areas of responsiblity, that is, if it were modular, then Linus would not have to even look at patches for systems he had delegated.
He does a DAMN good job, though
So does Alan Greenspan, but central planning still has its limits.
People who don't realise that they can't patch
their own kernel to add the kernel debugger
It's more that, because good support for debuggers is kept out of the kernel, applying one of the kdb patches doesn't help as much as it should. We've tried them all.
However, I believe he will sooner or later begin using BitKeeper. Maybe already for v2.5
That would rock!
But you have to realise, that it's impossible to work 48 hours/day.
Viro is notorious for making changes without warning and then not documenting them. It's hit or miss with everyone else. And I'm not expecting people to work 48 hours a day; I'm saying, if you don't have time to do it right the first time, do you have time to fix it later?
you'd probably not appreciate the kernel no matter what changes are made.
Not true. If I simply hated Linux and didn't care if it improved, I would simply have kept my mouth shut and used FreeBSD, or something. THe fact is, I want it to improve. I like it. I'm not blinded to its faults, though.
The reason I considered your post trolling wasn't because of your opinions on Linux, but because you implied that people reading Slashdot automatically would flame you, send spam to you, direct ICBM's at your house etc., just because you have a different opinion.
Only because it's happened in the past. The voice of experience and all. I figured that if I pointed out in my message that that type of response isn't constructive, it would prevent that type of response. It has worked so far, for the most part. Lots of people start of posts of controversial opinions with "this isn't a flame; don't flame me."
Thanks! I'm glad someone is willing to debate the ideas I presented, and not my spelling, shoe size, etc.
________________________________________
Thanks. That was a good reply.
/. replies and personal communication from my friends and co-workers, people want it to happen. Setting up the political structure will take some time. Want to help?
The mantra 'modular gooood - spaghetti baaad' is too simplistic
It certainly is -- as is any type of fanaticism or dogma.
However, spaghetti code does have one virtue: it is often faster.
Even NT, which is very modular, compromised with the "fast path" i/o machanism. However, they started from a position of modularity, and added a hack. Linux is the other way around. We won't discuss win32, because it's utter crap. When I say nice things about NT, it's only about the David Cutler kernel.
the code produced by the other types of programmers - who heavily require debuggers - is sloppy and the result of confused thinking.
I'm not disputing that; it's true. However, engaging in social engineering rather than simply rejecting patches is silly and counter-productive. Even very good programmers can and do use a debugger productively. Bad code is bad, regardless of whether a debugger was used. Providing a debugger won't make a good programmer bad, and withholding one won't make a bad programmer good. It would be better to provide coding standards and/or guidelines and recommended testing procedures, and allow a debugger, than to simply disallow a useful tool because it can fall into the wrong hands. If there were standards and even plans, then a lot of patches could be rejected because they don't meet the standards, rather than "Linus doesn't like it." And there would probably be fewer bad or useless patches if there was a plan and guidelines, because people would know from the outset what is expected. Take that one step further, and provide some public coordination and documentation of efforts, and I think it would be better still.
Let me suggest that you attempt to create your own kernel based on your ideas of what a kernel ought to be. If you are right everyone will be able to see that it is so.
This is correct, and I've been considering forking the kernel with the aid of the big outside players (IBM, SGI, etc.) and starting an Advanced Linux Kernel Project. Based on the reasion I've gotten to my post via email,
________________________________________
he OOM-killer (at least as of test10pre3) does NOT kill kswapd or X11, unless those really ARE the villains.
...assignments for different CS-classes simply having the bugs patched over by if-clauses, from people that have traced the code to see where it fails
/. probably don't.
I cannot think of a single acceptable reason for the OOM code to kill kswapd. That's like the kernel wiping its nose with a revolver.
Because if kswapd, a kernel-thread, is buggy, your system will die anyway. But it isn't, and it won't get killed.
Kswapd regularly dies on my 2.2.16 + USB machine. 2.2.16 is supposed to be a stable kernel -- release 16 of a stable kernel. I can oops the kernel by merely plugging in my scanner to the USB port. Yay.
But the VFS in Linux is not very hard to write a filesystem for,
A simple one, no. One that must make use of the broken spinlocks and semaphores, while avoiding the wrath of bdflush and kupdated, is very hard to stabilize on Linux. There are many unintended consequences that pop up due to the spaghetti.
ReiserFS wasn't working properly
True, but interesting that it was stated during the 2.3 series that Ext3 would probably be included in the 2.4 kernel, even though it was less capable, less stable, and in less widespread use than ReiserFS at the time.
This isn't about narrow-mindedness, it's about sanity and interoperability. It's about not making the same mistakes Microsoft keep doing over and over again. NTFS streams ARE a complete mess. Try to map them sanely into the Unix-world, and you'll see. Try to use tar to backup an NTFS-volume and see how much you'll preserve...
I.e., they're not Posix. As I was saying. Linus and I were arguing that, whether streams are posix or not is irrelevant, because there are many existing filesystems that people want and need to use from within Linux that use streams and/or EAs, and Linux would do well to provide clean support for them. Like you said, to provide interoperability and sanity. No one will accuse the current HFS method of posixizing a streams-capable filesystem of being sane. The notion of providing a way to support filesystem that provide streams/EAs was met with a quite visceral reaction from Viro, Tso and especially Cox. How do you plan to support all the features of NTFS, XFS, BeFS, HFS and HPFS on a VFS that respects only Posix? And incidentally, the tar format supports extended attributes, even though the current tar tools do not. Pax also supports extended attributes. If interoperability was actually the goal, then there would have been a discussion of how to provide support for streams without breaking the semantics of filesystems that don't support them. We even submitted a thought-out suggestion for namespace augmentation that would provide the needed support and compatibility for Posix filesystems. Victim of the killfile.
Oh, and about kernel-debuggers. Yes, Linus is violently opposed to those. But does that prevent YOU, or anyone else for that matter, from using one?
Yes. His refusal to allow support for KDBs means that they do not work well, or at all; unlike the kdbs of other OSes. "Oops" is not useful output in a lot of situations, noteably race conditions. I imgine there would be fewer race conditions inhernent to the kernel if there was a built in debugger, and there would be less code with undefined behavior if there was a debugger, and developers would be able to get a meaningful stack trace when their driver crashes if there was a debugger. What gooed does printk do when the kernel resets precipitously and cannot flush its output? Stating at the sudden appearance of the bios screen isn't helpful.
Pray tell me, if you don't want the kernel-developers to tell you to fork your own kernel, and you don't want to submit changes to the kernel to clean things up because you don't like the development process, why DO you worry?
We do submit things. Cox even rejected a patch to provide 64-bit printk output on 32-bit platforms, twice. This, after developers are told they should use printk and not a debugger. Never mind that even printk is lacking.
Yeah... it really kept all the a[i]=i++ code out. And Linus doesn't have to accept code if he doesn't like it; why cripple the use of a debugger for the people would would actually make good use of it? The 1-st year CS students won't write worthy code whether or not they use a debugger, so why stop them? Unless it's just social engineering.
v2.3-series has been spent rewriting the VFS and the Network layer to be clean,
Not to mention the 2.4-test-pre-whatever series, which has also been spent rewriting the VM and VFS. Linus should never have attempted to force things by jumping the version number up. It didn't work, and merely caused a lot of frustration for a lot of people. Relabelling the kernel as "ready" didn't make it ready.
It is VERY unlikely that people are uninterested in the v2.4test kernels because they've lost their faith in the kernel development process. Why? Simple. Because most people that don't hang around on LKML or Slashdot don't even know about how the development process works. For that matter, most people hanging on
They do see all the delay announcements. They see the kernel not being released in two years. They see features being backported so that Linux can just keep up. Who will believe that the 2.4 kernel is ready when they finally announce it? They've announced 10 versions of 2.4 already, and none of them are production quality.
And, why won't Linus use CVS? Accidental additions can be backed out, the commit logs with provide a start for documentation (since the inner circle of kernel developers themselves don't write any), and it will allow better control of the process at large. Right now, all the major decisions are made off list between Viro, Cox, Linus, etc. and the rest of us get to hear about them only the next patch is released. There is never and intent or direction advertised before, and there's no documentation after. If they at least used CVS and let people read the histories, we would have a better idea of what few design decisions are made actually mean.
You know, you ARE really trolling.
That same comment is made any time any criticism is made of any aspect of Linux. It's lost its sting.
________________________________________
At least those DOS and Windows 1.0 apps will still run on Win98/NT
Actually, most Windows 1.0 apps won't run right, even on Windwos 3.1, and a lot of DOS apps will not run right either, if at all. In fact, the dos version of warcraft will reliably hang NT, even from a non-privildged account, just by being executed.
Most of the redhat releases were actually both binary and source compatible. Can't say that for even revisions of the same release of Windows.
________________________________________
you're karma whoring on Slashdot
I don't collect karma anymore. My karma did not rise because of the points allocated to my post by moderators. In fact, it got lower because of one "overrated" moderation.
Oh, and I've posted this as an AC
Coward.
You're the prefect example of the useless LKML/Slashdot knee-jerk closemindedness that's been so prevalent recently.
________________________________________
Moderation Totals:Flamebait=1, Insightful=1, Interesting=1, Informative=3, Overrated=2, Total=8.
... flamebait?
________________________________________
DOS -> windows 1.0 -> 2.0 -> 3.0 -> 3.1 -> windows 95 -> windows 95 osr1 -> windows 95 osr 2 -> windows 98 -> windows 98 SE -> windows ME. Also, OS/2->OS/3->NT3.1->NT 3.5 -> NT 3.5.1-> NT 4.0 -> SP1->6-> NT 5.0 (win 2k) -> datacenter, server, professional, embedded. And don't forget wince. There's actually more versions of windows than Linux at the moment.
________________________________________
I'd say that the reason that people aren't interested in the 2.4 kernel is they they have lost faith in the development process.
Over the last two years, people have repeatedly posted on the LKML in one way or another that the emperor has no clothes. They've been nice, they've been rude, they've even posted good ideas and patches to provide some clothes. But, universally, the response from the LKML acolytes has been a variant of "the emperor isn't naked; he is in fact wearing a 3-piece suit, and if you don't like it, you can get your own emperor, you idiot."
It's very sad. Criticism is what keeps any public enterprise honest and productive, and the denizens of the LKML don't have any tolerance for it.
The linux development process has little direction, no planning, little to no leadership, meaningless feature freezes, and little to no documentation and guidelines. The kernel itself *is* spaghetti code inside, no matter what people say. They try to maintain control over what people use by not exporting some functions from the kernel
It is very difficult to alter some part of Linux because of all the unintended consequences. It's difficult to get needed features and clean-ups into the kernel because of cronyism and a narrow-minded religious devotion to Posix. Go back and read up on the NTFS-streams thread for a good example of that (Alan and Viro actually invited everyone talking about streams to an off-list discussion, and then notified them that they had been added to their killfiles).
Clean code? Just look at the 2.4.0-test-pre-pooch-screw series of debacles, where the VM is rewritten every few weeks, and new features are tossed in while there's still massive bugs to fix in the code that's already there, and in spite of repeated "feature freezes". That would all be fine in a 2.3.x series kernel, but judging from the version number, "2.4.0-test" is supposed to be pretty stable except for bug fixes -- not have major features added and subsystems being rewritten.
Linux has terminal featureitis. No one wants to work on the hard things; they just want to add features. Quickly.
And Linus, to make things worse, claims that a kernel debugger is counter-productive; that debugging with printk puts hair on your chest. Never mind that you can't debug race conditions well, if at all, by adding printk statements everywhere, because they change the timing of the code when it runs. Never mind that essentially every other 'modern' OS includes a kernel debugger, and that many of those OSes are better designed, better implemented, and perform better and run more reliably than Linux (FreeBSD, HPUX, Solaris, and even NT come to mind).
Linus must be right. In fact, he's declared himself to be infallible -- he will not allow a kernel debugger to be added, and has publicly stated that he thinks people who use debuggers are dummies and that he won't work with them. But never mind that; he's the leader of the mo vmentarians
- set realistic goals for a release
- defer any further feature creep until the next
release
- concentrate on fixing bugs in the pre-release cycle
- aim for modularity, stable interfaces and good
documentation to make upgrades and new feature
addition easier and the learning curve less steep
- provide robust methods for troubleshooting the
system to make development and debugging easier.
Linux does none of these things. By design. So continue to kvetch about idiots like me (and IBM, and SGI, and HP, and Reiser, and about 1000 other people and companies) pointing out that Linux is fundamentally screwed.The most common response to criticism is a variant of "love it or leave it." Keep suggesting that we go write our own damn OS if we don't like it; your love it or leave it response will be accepted one day, and we will leave Linux. I actually think it would be a good idea for the major external linux players to fork the kernel, clean it up, and maintain their own version. I don't doubt that it would shortly become the defacto standard kernel, because it will be cleaner, more stable, more scalable, more extendible, and will probably be released on time and respect feature freezes. SGI, IBM, Reiser and a lot of other people and companies have a lot of good code and ideas to contribute, not to mention full-time developers, years of experience making scalable and robust systems, and a willingness to release all that work under the GPL. And if they fork the kernel, they can do it without having to be named "Ted", "Ingo", "Alan", "Linus" or "Rik".
One day the question will be, are *you* relevant? Why should we accept *your* code? Is it clean? Is it modular? Is it safe (see LWN article about C code with undefined behavior being included in the kernel). Of course, a fork can always be re-merged with the holy penguin pee version. In the meantime, all the people who want to run Linux on enterprise systems rather than PDAs and webpads can have a stable, working kernel with adequate features.
It would be useful if people would make substantive replies to this message, rather than engage in the usual comments about rioting, sending spam reports, saying "love it or leave it," moderating it as a troll, port-scanning my mail server, attempted hacks and other juvenile/illegal acts, sending spam reports, threatening violence, etc. Of course, substantive debate is really hard to come by on either the LKML or Slashdot, so I don't expect it. So, go ahead, get started telling me to sod off. I'll get back to switching over to FreeBSD, although I would prefer if someone would take up a rational refutation of this message instead. Show me the Emperor's Clothes.
________________________________________
Funny that this showed up on Slashdot before the LKML, especially considering the huge amount of arguing that has gone on about ReiserFS on that list.
________________________________________
all the talk about freedom is crap
Our Anonymous Coward friend has, in fact, made it abundantly clear that he doesn't want freedom; he wants free stuff. AC For President! He will make us his slaves, but feed us.
________________________________________
The guy making 15k is going to pay 1.5k in taxes.
Not true. All of the flat tax plans call for a flat tax on all income over a certain amount, and it's typically fairly high, like $60,000. Your $15k/year example guy would pay no taxes.
________________________________________
why cant we accept paying political campaigns to remove corporate influence.
Mmmm... welfare for the political class.
________________________________________
Freedom or capitalism, you can't have it both ways.
Freedom and capitalism go hand in hand. You'd be better off saying "socialism or freedom; can't have it both ways"
The Libertarians would be telling you to vote for Nader if they weren't all rich.
Breathtakingly silly. Nader is much more of a socialist than a capitalist. He wants a nanny-state -- exactly what Libertarians don't want.
________________________________________
he will only help empower the already over-powered multinationals.
Not true. Libertarian government would kick coporations off of the public teat and make them accountable for fraud.
It would be cool if the corporate death penalty were revived as well.
________________________________________
If your the backbone of the democratic party with weak convictions been like the parent post.
... I have no idea what that means.
________________________________________
I love this strict almost fundamentalist Constitution talk, ever hear of amendments?
"fundamentalist Constitution talk"? The Consitution is the Supreme Law of the Land. Pointing out that the government is in violation of the supreme law of the land isn't "fundamentalism." It's not hard to understand the meaning of words like "shall make no law," "shall not be abridged," and "reserved to the states and people". What good is a supreme law of the land if it's not actually followed?
Or those part of the evil empire also?
No, they're part of the system. The idea is that, when large changes are made to the supreme law of the land, there must be vast support for it. As opposed to simply issuing an executive order.
________________________________________