Slashdot Mirror

OTOH, if birth control is widely available, pre natal care is available to all comers, and food, shelter, and education is given to all children, without question or exception, then one can imagine a world in which every child would be wanted. Likewise, if maximum information and open debate were seen as a asset, and everyone was encouraged to have their say, all everyone was honestly listened to, and no one would retaliate based on personal superstitions, then one could imagine a world in which everyone could be open and honest with their opinions.

In the real world, though, significant militant groups enjoy killing people who disagree with their superstitions. For example, groups have felt the right to kill people who believe differently from them, following a tradition that killed the man that believed that the heart pumped the blood. Clearly when the righteous feel the right to kill based on beliefs, anonymity is necessary.

But I will be a rebel and say that even in a perfect world where all superstition was gone, both anonymity and abortion would still have a place. No matter how careful and care full we are, there will still be that one case where a family might have to choose between the mother and unborn child.

RFC 2324 dealt with just this sort of thing.

It only requires one extra bit if they would just implement RFC 3514. In case anyone thinks it is obsolete, the IETF RFC 3514 Working Group (IETFRFC3514WG) should have it updated for IPv6 by 4/1/09.

Learn the Art of Unix Programming, because the programming culture is very different to Windows: http://www.faqs.org/docs/artu/ Programming languages are not so different to Windows.

Not so good an idea. Then you ould have to create an exception for IP over Avian Carriers, and Ip over Avian Carriers with Quality of Service.

http://www.faqs.org/rfcs/rfc1149.html
http://www.faqs.org/rfcs/rfc2549.html

Not so good an idea. Then you ould have to create an exception for IP over Avian Carriers, and Ip over Avian Carriers with Quality of Service.

http://www.faqs.org/rfcs/rfc1149.html
http://www.faqs.org/rfcs/rfc2549.html

On top of this TCP hasn't seen a major update since the 80's.

Uhh, TCP Vegas, TCP New Reno, BIC and CUBIC? All of which have been implemented in the Linux kernel? TCP has only been standing still since the 80's if you're using an OS from the 80's... or a Microsoft OS.

Note that the only one of those which made it into an RFC is New Reno, aka RFC 2582, which has been implemented in the Windows TCP stack since Vista, along with a number of other recent RFCs.

The others are basically different suggestions for implementing TCP congestion control. Microsoft has its own variant of those (Compound TCP, which is quite similar to TCP Vegas and has also been ported to Linux).

Your 1980s comment is not quite up to date, of course. Microsoft has been sticking to their BSD-based implementation of the TCP stack for quite a long time (too long in fact), but with Vista it's been undergoing quite a bit of change. I know it's unpopular to say something in favour of MS and/or Vista here and I'm far from being a MS apologetic, but it's worth actually reading their Cable Guy columns every now and then to be up to date with regards to what the Windows network stack actually does and doesn't do - especially if you are a sysadmin or interested in developments in the TCP arena.

On top of this TCP hasn't seen a major update since the 80's.

Uhh, TCP Vegas, TCP New Reno, BIC and CUBIC? All of which have been implemented in the Linux kernel? TCP has only been standing still since the 80's if you're using an OS from the 80's... or a Microsoft OS.

Note that the only one of those which made it into an RFC is New Reno, aka RFC 2582, which has been implemented in the Windows TCP stack since Vista, along with a number of other recent RFCs.

The others are basically different suggestions for implementing TCP congestion control. Microsoft has its own variant of those (Compound TCP, which is quite similar to TCP Vegas and has also been ported to Linux).

Your 1980s comment is not quite up to date, of course. Microsoft has been sticking to their BSD-based implementation of the TCP stack for quite a long time (too long in fact), but with Vista it's been undergoing quite a bit of change. I know it's unpopular to say something in favour of MS and/or Vista here and I'm far from being a MS apologetic, but it's worth actually reading their Cable Guy columns every now and then to be up to date with regards to what the Windows network stack actually does and doesn't do - especially if you are a sysadmin or interested in developments in the TCP arena.

On top of this TCP hasn't seen a major update since the 80's. Most of it was implemented to deal with a very different internet than the one we have today. If you can side step TCP's shortcomings by doing the congestion control more efficiently at the application level then why not give it a shot?

Uhh, TCP Vegas, TCP New Reno, BIC and CUBIC? All of which have been implemented in the Linux kernel?

TCP has only been standing still since the 80's if you're using an OS from the 80's... or a Microsoft OS.

the kernel application binary interfaces are a moving target.

That's why we have glibc, which abstracts that ABI from applications.

Kernel driver interface - the horse was already beaten to death many times ( see here ).

a consistent configuration system, to enable distribution;

Windows tried that with Registry - and it didn't worked. And it will never work since "one size never fits all" requirements of all applications.

native file versioning;

Was tried many times before and failed miserably. As long as majority of files are blobs, versioning on level of file system makes no sense. Versioning on level of applications is implemented already more or less everywhere it was needed and SVN/git is there for the rest of applications.

audio APIs;

See ALSA and its user-space libraries.

See SDL.

and the integration of X11 with apps.

As was shown by FreeDesktop initiative not really needed nor X folks want to be bothered by all the end user bells and whistles.

Finally, he argues that Linux needs a committee to insure that all GUIs work consistently and integrate better on the back-end with the kernel.

Committee?? Buahahhahahaha!!!1!!cos(0)!!!!!!!

All what he says was tried before (see (11)) and generally can be described as "failed".

This touched a nerve. I've been sysadmin'ing for a long time now (well, not THAT long. 10 years or so), and I've seen my share of abusive system administrators, it annoyes me every single time.

In my experience, about 98% of the time, there are only two ways we learn. One is through pain. The network breaker, among many flaws, had insufficient caution, but I'm sure the pain of humiliation here taught him some. (That's one of the skills he'll need if he ever wants to be a highly paid admin.) The other way is through observing the pain of others. By making a semi-public example of the yutz, a room-full of network engineers (and I'm sure, a lot of their friends) got a great example of how not to behave. You can bet that at least some minor fuckups were avoided thanks to this.

People don't learn anything useful from pain, they only learn behaviorism - and then they learn that their senior system administrators is some elitist assholes. Okay, the latter is somewhat useful to know.

Sysadmins are often dicks to fools for a reason: it helps a lot in their work. I didn't like hating everybody all the time, so now I'm a recovering sysadmin. Bitch all you want, but however unforgiving sysadmins are, the machines they run are far less so.

Many system administrators are exactly as unforgiving as the machinery they run - and it don't have to be that way. System administrators must provide (as everybody in IT) vertical support for the entire organization, not the other way around. Many system administrators don't realize this. Instead they only accept one truth. Their own.

you're a dick. given that this guy is low salary he probably doesn't have a lot of experience. you could have shown him the error of his ways, instead you publicly embarrass him in front of the whole company. glad I don't work with you.

On the one hand, you're right. Embarrassing the idiot was clearly a dick move.

On the other hand, this is a very useful bit of dickishness. The idiot didn't just make a mistake; he made a mistake with major consequences to a lot of people, and he made a mess that his betters had to clean up.

In my experience, about 98% of the time, there are only two ways we learn. One is through pain. The network breaker, among many flaws, had insufficient caution, but I'm sure the pain of humiliation here taught him some. (That's one of the skills he'll need if he ever wants to be a highly paid admin.) The other way is through observing the pain of others. By making a semi-public example of the yutz, a room-full of network engineers (and I'm sure, a lot of their friends) got a great example of how not to behave. You can bet that at least some minor fuckups were avoided thanks to this.

Sysadmins are often dicks to fools for a reason: it helps a lot in their work. I didn't like hating everybody all the time, so now I'm a recovering sysadmin. Bitch all you want, but however unforgiving sysadmins are, the machines they run are far less so.

At least link to the RFC

Compared to other non-Microsoft SMB/CIFS client implementations, the OS X SMB client is deficient.

It does not support DFS, which basically amounts to having symlinks from one CIFS share to another (so a hierarchy of directories spread across many servers can be accessed via one namespace.) But Linux's cifs client driver can use it and Samba can host it.

Don't believe everything you read about Samba.

Its DFS support is shoddy at best and catastrophic at worst. It just fails to mount on Fedora 6 (samba 3.0.24-7, kernel 2.6.22.14-72.fc6), and causes a kernel panic on Fedora 9 (samba 3.2.4-0.21, kernel 2.6.26.5-45.fc9.i686). Of course, I am using Windows 2003 R2, which has improved DFS (which, is absolutely killer, especially the much better replication).

As opposed to the Windows paging system? Has the author used a Windows OS lately? Swapping is a *bleeping* killer! Especially when you have more than enough memory not to swap. :-/

No OS performs well while swapping heavily, but OS X seems to swap too often. I'm at 4.65 GB of swap used right now on a system with 4 GB of RAM, 3.94 GB of it used. The sum of real memory allocated by all processes is less than 3 GB. In my experience, this is worse than Windows or Linux. It's not rare for applications or the entire system to respond slowly for seconds at a time.

Windows lets you disable or limit swap easily, and Linux gives you lots of control over how much swap you have and how it is used.

Macs support CIFS/SMB pretty darn well these days. I keep hoping that someone will come up with a better replacement, but CIFS/SMB will continue to work until that day comes.

I disagree. Compared to other non-Microsoft SMB/CIFS client implementations, the OS X SMB client is deficient.

• It does not support DFS, which basically amounts to having symlinks from one CIFS share to another (so a hierarchy of directories spread across many servers can be accessed via one namespace.) But Linux's cifs client driver can use it and Samba can host it. Closed-source DAVE supports DFS on OS X.
• By default, the OS X SMB client puts desktop folders and dotfiles on remote SMB shares.
• The smbfs driver in OS X is known to cause kernel panics.

It's not like Apple is a struggling company who can't afford to improve their SMB/CIFS client. It's not like the required protocols are so difficult to implement that no one can figure it out. It's not like Microsoft is suing anyone who dares implement certain features.

It's not like they're ignoring the SMB client altogether. In Leopard, they finally introduced SMB packet signing (which other non-Microsoft clients have supported for longer, including Samba's userspace smbclient.) And performance seems to have improved; in unscientific testing with no attempt to improve performance on the Samba server or client, I went from 45 mbytes/sec SMB performance in Tiger in any condition to performance very close to the maximum possible given the disks involved - about 70 mbytes/sec.

He's using TCSH! That's BAD FOR YOU!

Ok, enough offtopic. This is actually pretty cool, considering our development environment is clusters and clusters of IBM P-Series LPARS, and our codebase is (A) disgustingly huge, and (B) actually pretty amenable to parallelized make.

FINALLY, I can justify to my boss that browsing /. is research! (Now if I could just make a good case for 4chan...)

If the same behavior - one kid bullying another or saying unkind things - was occurring in a non-electronic medium, we usually would consider it the sort of thing where it's a matter for the kids to settle among themselves, or at most, by the kid's parent talking to the bully or the parent, which then usually stopped it. But now, we're going to add the ISP, school authorities, police and courts into the mix and create a tempest in a teapot.

Brilliant. That's exactly the problem. Well said.
Leaving it alone is the best thing for it.


And it's "Down, not Across" (the official motto/catchphrase of alt.sysadmin.recovery).

RFC3251 - Electricity over IP

With tcsh, I just alias cd to pushd, and get the same effect. If it has a built in way like your zsh example, then I don't know about it.

(I have read the csh programming considered harmful document http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/, but still like tcsh. I use probably 3 features above csh.. I just have the syntax of csh/tcsh in my head. Once in a _rare_ while I do lament the inability to redirect stdout & stderr separately.)

http://www.faqs.org/rfcs/rfc3514.html or as I like to call it, the "bert bit"

the USAF should enforce ALL RFC's ( postmaster@domain anyone?) and those that
do not comply get a thrashing that ED209 would get a chubby over.

Someone, someday will carry lost a USB thumbdrive carrying the sensitive information.

Perhaps we need a new RFC, similar to this one [RFC1149], for USB thumbdrive.

I guess it depends on how you define sleep. We all can do some stuff in our sleep (breathing for e.g.). I'm no biologist but I *guess* an animal could sleep and have wings set to the same automatic response as breathing, waking up when it got tricky (turbulance etc).

But this does look interesting in terms of data delivery over avian carriers. Tiny birds ... I guess we'd be talking small MTU.

my MySQL server is having problems

I can fix your problem in 10 steps...

Actually, both sides are at fault in the spirit if not in the letter of the RFC.

The broadcast flag is included as a work around for a nasty catch 22 situation that some network interfaces might suffer from, namely not being able to receive unicast IP packets until they have been configured with an IP address. This means that such an interface cannot receive its own IP address in an IP packet which is what the DHCP server would normally use.

Acording to the DHCP RFC ( http://www.faqs.org/rfcs/rfc1541.html )

"A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0."

So Vista is - was (because it was fixed in sp1 I believe) - morally at fault because its IP stack is capable of receiving unicast packets before the IP address has been configured. However, the word "should" rather than "must" was used so Microsoft is still in compliance with the letter of the protocol.

On the server side:

"A server or relay agent sending or relaying a DHCP message directly to a DHCP client ... SHOULD examine the BROADCAST bit in the 'flags' field. If this bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast using an IP broadcast address (preferably 255.255.255.255) as the IP destination address and the link-layer broadcast address as the link-layer destination address."

Again, it says "should" instead of "must" and so the server side is also morally wrong, but still in compliance with the protocol.

The bug is actually in the RFC

You were actually serious!

http://www.faqs.org/rfcs/rfc1149.html

To be fair, ARM and MIPS don't need cutting-edge performance. They are fabbed on whatever slightly older, absolutely dirt-cheap process is available. They're so small and low power already that a process shrink or two doesn't noticeably affect the overall performance of the embedded device.

But the DEC Alpha did need cutting-edge performance. Originally DEC fabricated the chips but they contracted out the fab to the Korean business Samsung.

Falcon

Maybe we can bring back the +++NO CARRIER and RFC1149 "classic" connectivity jokes from the 90's, too!

Or not.

And as for my book recommendation, I suggest "Code Complete"

A fantastic book. I'm just surprised to see so many /.ers recommending something issued by Microsoft ! Another good one is 'The Art of Unix Programming' by Eric S. Raymond (yeah, that one). You can read it online, too. http://www.faqs.org/docs/artu/

• minimize delay
• maximize throughput
• maximize reliability
• minimize monetary cost
• normal service

I believe an extension also had a "maximize security" option as well.

Alas, almost nothing supports these flags, and I believe a later RFC has proposed reusing the QOS bits in the IP header for an incompatible use.

It's not just a principle of project management, it's also an RFC (1925, 7a):

http://www.faqs.org/rfcs/rfc1925.html

However, I do know of a really good author, that is a "dead tree" author, for C: Herbert Schildt.

I used to recommend his books too, but he has a bad reputation among many developers:

Why do many experts not think very highly of Herbert Schildt's books?

A good answer to this question could fill a book by itself. While no book is perfect, Schildt's books, in the opinion of many gurus, seem to positively aim to mislead learners and encourage bad habits. Schildt's beautifully clear writing style only makes things worse by causing many "satisfied" learners to recommend his books to other learners.

Do take a look at the following scathing articles before deciding to buy a Schildt text.
http://www.lysator.liu.se/c/schildt.html
http://herd.plethora.net/~seebs/c/c_tcr.html

The above reviews are admittedly based on two of Schildt's older books. However, the language they describe has not changed in the intervening period, and several books written at around the same time remain highly regarded.

The following humorous post also illustrates the general feeling towards Schildt and his books.

http://www.qnx.com/~glen/deadbeef/2764.html

There is exactly one and ONLY one C book bearing Schildt's name on its cover that is at all recommended by many C experts - see Q 25.

cplusplus.com?

good lord no. use it for iostreams quick reference at most.

http://www2.roguewave.com/support/docs/sourcepro/edition9/html/stdlibref/index.html

http://www.dinkumware.com/manuals/Default.aspx?manual=compleat

note that dinkumware wrote much of msvc's c++ standard library.

http://www.gotw.ca/gotw/

http://www.faqs.org/faqs/C++-faq/

Are you seriously insinuating that putting premium fuel in your auto is a good idea, regardless of savings? Autos take a certain octane of fuel because they are tuned to run on that octane. Using a higher octane will give you slightly better power, and thusly fuel efficiency, but, over time, the wear on the parts and the reduced lifespan of the vehicle will NOT amount to the money saved from the slightly higher efficiency.

Well, I put 100,000 or so miles on the 76 corolla.
The 79 Corolla I bought later I gave it up when it had 360,000 miles on the clock. Well, it could have been more, I saw zero three times. I can't say I got 40mpg on the 79, I only got 35 on Premium, 28-30 on regular. IIRC the compression ratio was 9:1, so that does actually call for something higher than 87 unless you have fuel injection and computerized ignition. If I wore out the engine more quickly, and gave the car away while it was still running, I must be doing something right.

http://www.faqs.org/faqs/autos/gasoline-faq/part3/section-1.html

I already posted the old list of compression ratios to recommended octane rating.

You sir, are an idiot. Premium gasoline does not result in better mileage. Period.

It really depends on the vehicle. The octane rating isn't so much the number of octane molecules in the solution, but rather it's rather it's ability to resist premature detonation.

Research Octane Number (RON) is judged by running a fuel in an engine in contrast to iso-octane and n-heptane.
Motor Octane Number (MON) is similar but tested under a load, with a preheated fuel mixture, and variable ignition timing.

It's a little confusing for imports as they often recommend a fuel rating based on the RON number, where in the US and Canada we take the average of the RON and MON, where the RON is typically a higher number. A 91 RON might be equal to 87 RON+MON/2.

Firstly, we have MJ/liter
Regular is about 35
"Premium" is about 40

Or roughly 12.5% higher for "premium" using the numbers pulled from my ass.

Now 12.5 more energy per volume shouldn't equal 33% more work done, but keep in mind that the numbers are not so much a measure of energy per volume but rather how the fuel knocks in contrast to to iso-octane and n-heptane. Resisting predetonation is likely what I experienced. This typically isn't really a factor unless you're talking higher compression ratios like 9:1 and above.

http://www.faqs.org/faqs/autos/gasoline-faq/part3/section-1.html
Compression Octane Number
    Ratio Requirement

05 to 1=72
06 to 1=81
07 to 1=87
08 to 1=92
09 to 1=96
10 to 1=100
11 to 1=104
12 to 1=108

Presuming this list is in RON, I believe 91 RON = 87 RON+MON/2
This is old data, before computer control and fuel injection were common place.

the evil bit.

Even Berners-Lee is new here!

No, they'll just be using their routers. Packets for terrorist training videos, per RFC 3514, will have their evil bit set.

Oh, sure, the practical uses. I hear 'Delay-Tolerant Networking', and I think 'carrier pidgeon'.

"firewalls can't protect against tunneling over most application protocols to trojaned or poorly written clients .. Tunneling ``bad'' things over HTTP, SMTP, and other protocols is quite simple and trivially demonstrated. Security isn't ``fire and forget'' ..

In general, a firewall cannot protect against a data-driven attack--attacks in which something is mailed or copied to an internal host where it is then executed ..

A strong firewall is never a substitute for sensible software that recognizes the nature of what it's handling--untrusted data from an unauthenticated party--and behaves appropriately"

Well then... given it's tax dollars, they probably implemented the wifi link via text messages :-)

I was personally hoping they were going to implement it via RFC 1149 (IP Over Avian Carrier)

The negative connotation is that when any given thread has reached a reference to Nazis, it's use-by date has expired and the thread will devolve into flames either about (a) the Nazis, or (b) Godwin's Law. Which amuses me, since it places the Law on the same level as the Nazis...

http://www.faqs.org/faqs/usenet/legends/godwin/

"They got basic TCP/IP running, then email on it, then started building local network apps, which they discussed on the network in "Request for Comment" messages which spec'ed the new app/protocol."

Mostly true, except for the TCP/IP bit. RFC 1 specified a much older protocol. ARPANET didn't fully switch over to TCP/IP until 1983.

Those early RFCs are fascinating reading actually. http://www.faqs.org/rfcs/

"They got basic TCP/IP running, then email on it, then started building local network apps, which they discussed on the network in "Request for Comment" messages which spec'ed the new app/protocol."

Mostly true, except for the TCP/IP bit. RFC 1 specified a much older protocol. ARPANET didn't fully switch over to TCP/IP until 1983.

Those early RFCs are fascinating reading actually. http://www.faqs.org/rfcs/

The mention of gardening brought to mind section 5 of the alt.sysadmin.recovery FAQ. Well worth a read.

I would recommend IPv5

IPv5 is the Internet Stream Protocol.

âoeTrolling is basically Internet eugenics,â he said, his voice pitching up like a jet engine on the runway. âoeI want everyone off the Internet. Bloggers are filth. They need to be destroyed. Blogging gives the illusion of participation to a bunch of retards. . . . We need to put these people in the oven!â

I listened for a few more minutes as Weev held forth on the Federal Reserve and about Jews.

http://www.nytimes.com/2008/08/03/magazine/03trolls-t.html?pagewanted=4&_r=1

I think everyone who wants to know about trolls should read this article. I didn't know that debates like this got Godwin's law applied to them so regularly, even by the trolls themselves.

I have to say that if Quanxi is at roll, or a counter-troll, I've never encountered such paranoid rudeness in my life and had it so tacitly accepted. I don't think the problem is Slashdot, because this must happen on other parts of the net. In general, Slashdot has less trolly activity than any other forum I've been on, but then again I browse at +2 normally.

As a BSD user ... I run into alot more sh, ksh, csh, and tcsh.

Haven't they heard the news in the BSD camps? Scripting in csh is considered harmful. ;)

In all seriousness, having scripted in both, I would consider bash more powerful than ksh, and I avoid csh/tcsh scripting for some of the (still valid) reasons listed in the legendary tome linked above.

(Although, if performance isn't an issue, I usually attempt to stretch good old /bin/sh to its limits first. I even had it emulating expect for one task, sandwiching telnet between two scripts where the later sent signals back to the first... It worked, and kept me from having to install another package on a rigorously locked-down Solaris 8 box.)

I'm just waiting for an update to the network stacks and routers to offer the option to set a flag which tells it to make every possible effort to avoid routing data over a network in the US :-)

Steve Bellovin already thought of that we all thought it was a joke, in light of AT&T wiretapping I'm not so sure :-o

There is already such a solution. It's called RFC 2369, and it dictates headers to be inserted into every message. It's existed for years; the problem is webmail and most mail client developers are too stupid or too selfish to implement support for these headers.

xnest will do that, all it would take was a kind of xdm/kdm/gdm that when another user logged in, it would start another xnest and divide the screen...
the new multipoint support could help on the keyboard and mouse...

for plain multiuser, check the howto

DecNET is a protocol suite. There were several DecNetTCP/IP gateways, back in the day -- late 80s, I guess. They may still exist for all I know. c.f. RFC 1006.