Wrong. You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be), not if you want to prove authority (that the resource is being generated by the correct host) or integrity (that the resource data hasn't been altered). Go read ISBN 0471117099 for practical algorithms if you like.
Meanwhile, existing attacks on DNS have involved subverting authority (by transferring names between nameservers without permission) and integrity (through cache poisoning) and not on identity (which DNSSEC spends considerable complexity on).
DNSsec is designed so that you can do offline signing of data.
Wrong. Check RFC 4033 sec 3.1: It breaks Dynamic DNS if you sign your data offline.
I couldn't understand your VER proposal at all
There's a lot you couldn't understand. Asking questions can often help solve that problem.
Ummmmm, I hate to do this - god I hate to do this, but I'm actually going to support MS on this one.
Ummmm, why?
I wrote Netscape 3 applications that performed asynchronous javascript very well- far better still even than Microsoft's broken MSXML control. There's no reason that they couldn't have been made to work with Netscape 2 (although not quite as transparently).
Five minutes of looking elsewhere in the comments of this news and you'll find others who have done it as well.
I mean, you weren't there, so what the fuck do you think gives you the right to write history about it?
Another word for "security early adopter" is fool.
DNSSEC is not secure because it doesn't address the fundimental issues with security and nameservers.
* It doesn't stop cache poisoning attacks- a client resquesting a name from a poisoned cache won't get the key so they won't know anything is wrong.
* Breaking the nameserver itself gives you the keys as the nameserver is required to sign the resource records, so in this case, it gives people a false sense of security that they don't have!
* Finally, as it stands, DNSSEC perscribes to give a particular company power that hasn't demonstrated that they're trustworthy enough to hold it. You can't get a DNSSEC certificate right now unless you make your own, and even one day, if someone will sign DNSSEC certificates (like Verisign), whos to say someone won't get them to sign a bogus certificate (HINT: Verisign was already convinced to sign a code-signing certificate for someone claiming to be Microsoft Corp- are we supposed to trust these people?)
A better option would be to record a new RR type, like "VER" which acts as a verifier for (all) other data- the result contains an indexed hash of every response the server can give and the whole shebang is signed by a key that's signed by the immediate parent of the zone. Timelimit it and you're CURRENTLY safer than anything DNSSEC offers. VER would not be generated by the DNS server itself, but would have to be updated periodically all the same. It would also be big, which would mean likely TCP connections...
A better option would be to continue using in-transport mechanisms like S/MIME, PGP, SSL, or SSH that are ALREADY DEPLOYED.
A better option would be to do away with all that is DNS and make something good.
But nowhere is it even an option to deploy something that doesn't do anything but MAYBE produce a false sense of security.
This is one of the biggest lies that Judges and Lawyers to this day try and convince jurors.
It's unfortunate that Judges aren't required to take an oath before instructing the Jury on legal matters.
Jurors are following the law - whether they or you know it or not, when they decide whether the Judge is being a cockhead, the law is stupid, or that dumb slut had it coming.
This is one of the biggest lies that Judges and Lawyers to this day try and convince jurors.
Jurors not only have the right, they have the duty to decide whether the Judge is being a cockhead, the law is stupid, or that dumb slut had it coming.
Next time you think Jurors are required to decide on facts, or don't have the ability to rewrite law from the box, I urge you to pay attention at the next Michael Jackson molostation case, or if ever OJ Simpson decides to remarry.
You didn't read what I said, did you? I can't put it at the end because you can't jump over a variable declaration in C++. (Because you can't jump into a greater scope than the one you're currently in, but you can jump into a lesser one.)
I misread these:
Object2 o2();
as
Object2->o2();
(blaming slashcode) instead of what you probably meant.
And I can't use exceptions because this is an embedded device where I can't afford the 2kB-per-stack-frame hit that enabling exceptions in gcc gives me.
I covered that: or you shouldn't be using C++...:)
Regarding stack overhead, have you heard of inline functions? You can still write good readable code and let the compiler do all the dirty work, thank you very much. You may not feel comfortable enough to take advantage of the compiler with your current skills, but maybe in another 10-20 years...
You're kidding right?
Let me guess, you also run everything with -funroll-loops, don't you?
It's the opposite, 10-20 years ago I was quite comfortable using gotos - before I learned the basic principles of good C programming, mainly how to avoid spaguetti programming and break down your code into smaller meaningful routines.
I'm so glad the Linux kernel developers are 10-20 years behind you then.
Goto doesn't produce spaghetti code- you do. That's the problem. If you want to blame it on goto, fine, but inlining functions far away from their exception handlers is still spaghetti code.
By the way, most C compilers don't avoid the stack operations when inlining- most of the time they can't- they simply avoid the call routine.
You've either duplicated finalization code (by putting it before each return), or performed it in the calling function which would mean additional stack operations).
Your solution is either less readable or (much) slower.
Real programmers know that goto has it's purpose and don't hide from good tools. If you can't use goto properly, that's fine- maybe in another 10-20 years of programming you'll feel comfortable enough with your skills to use it.
If fn2() takes several arguments, you've done extra stack operations. Your exception handling code is also far away from the code that generated the exception.
It's slower and less readable (consider if "Do something useful" is quite long)
Re:GOTO Considered Harmful since at least 1968
on
Goto Leads to Faster Code
·
· Score: 1, Insightful
Agreed. GOTO is excellent for exception handling. People are often taught to do blocks like this:
done = 0; for (i = 0; i < 100; i++) {
for (j = 0; j < 100; j++) {
if (sc[i][j] == ch) {
done = 1;
break;
}
}
if (done) {
break;
} }
Goto simply makes it more readable:
for (i = 0; i < 100; i++) {
for (j = 0; j < 100; j++) {
if (sc[i][j] == ch) goto DONE;
} } goto FAIL; DONE: ... FAIL: ...
... and lo, compilers will often produce better code with this construct. So you get more readable, faster code.
In general, I find it easy to follow as long as gotos always go the same direction (down)- and that we only have one or two labels in a function- we're fine.
Although, also in general, people who use gotos going up, or have more than two labels in their functions, or that otherwise avoid goto like it's some sort of plague tend to have other problems.
autopackage is probably the current best tool for this. It makes a single, easily installable (and removable) package while coercing my system's GCC and libs into versions that are suitable for other distributions.
It works very well for me: Debian, Ubuntu, SUSE, Fedora, Gentoo, and Mandrake users have reported success with these binaries built with (gasp) a lone FC4 machine.
One day, I'll actually do a proper release and six years later it'll show up in the next Debian release. Then your fancy apt-get tools will work.
And to kneejerk jackasses that say "just release the source"- you must realize that the source is good for you and me (well me anyway, I cannot speak for you, obviously), the people who USE these programs have absolutely NO INTEREST in doing the work that I have just done for my own purposes.
Plus, having them use a single binary means that it's very easy to debug with nothing more than a core file.
Oh, and I suppose I am giving the submitter the benefit of the doubt that we are indeed talking about Free Software, aren't we?:)
Agreed. I do however, have a very different requirement:
I think it's important that I be allowed to fix my servers and workstations, and that I be allowed to redistribute my fixes as I see fit.
Microsoft however, doesn't think I should be allowed to fix my servers and workstations. They have even gone so far as to convince a very large number of people that it's illegal for me to do so.
Right now, it may not matter so much, but in the future, it's not going to be x86 and some APIs that matter, it's going to be Digital Restrictions Management (DRM), and with that, I won't be allowed to do the things that I presently take for granted (and anyone else who uses my software- often without realizing it) unless I manufacture my own motherboards.
In the meantime, I am completely opposed to MS, as a steady source of income for me as I consult and help people keep those machines running is very important to me.
I can understand if it's not important to you, but please don't confuse the issue. It's not about reliability, or some feature set, or even usability. It's freedom.
If that freedom didn't exist, Windows certainly wouldn't have anyone to compete with, and you'd we living with the reliable, interoperable, supported, reasonably well priced, configurable and flexible system that is Windows NT 4.0.
Maybe that appeals to you- after all, you'd be doing more reinstalls, and as a consultant that would mean more income. But don't even suggest for a moment that you're using the right tool for any job when you snub freedom.
I concede that you don't care what OS you're running, but I think your reasons why are deplorable.
Never mind the fact that one there are such things as dual-stack hosts and 6-over-4, making the transition gradual enough for most people not to notice... Never mind the fact that A6 records have been deprecated for more traditional AAAA records... Never mind the fact that we are at an early stage of a long transition (the official line, IIRC, is for universal IPv6 adoption by 2020 or so)...
I never mind the fact because it isn't: IPV4-in-IPV6 isn't a standard, the most popular sites on the internet aren't "dual-stack hosts", and the most important ones aren't either. I also never mind the fact that the BIND corporation doesn't know that A6 records have been deprecated, or that doomsday folks keep pointing out the end of IPV4 addresses in less than 10 years.
I'm glad that univeral IPV6 adoption is hoped for by the designers of IPV6 by 2020 or so, but they still haven't told us how. I mean, I realize they have 15 years to do it, but given the fact that they've pissed away the last 10 I don't have a lot of faith in them.
Fanboys such as yourself talking about how gradual the transition will be are seriously confused: There are hosts on the Internet that still haven't migrated to MX records, and those have been a standard for MORE THAN 15 years, so I fail to see why anyone might think we can get EVERY SINGLE COMPUTER OFF THE INTERNET when we still have hosts that don't comply with current Internet standards.
Arrrggghhh! Publishing services in DNS is full of problems. Replication delays, no TTL, no URL, etc. Why not use a protocol that was designed to register and locate services - Service Location Protocol (SLP).
Err, how about the fact that SLP doesn't work on the Internet?
I mean, I'm happy to suggest we move multicast onto the regular Internet, and use ICMP host names while we're at it, but given the fact that people setting MLTTL=30 will eat my downstream's network alive, I don't think SLP is really reasonable.
Also it has a problem that the choice is too simplistic, for instance there's only a place for one _webcache._tcp.and.org where most applications allow different caches for http, https and ftp... plus exceptions.
The rest of the world solves part of that problem using split horizon and the fact that _httpproxy._tcp.example.org would be a perfectly adequate way to do it, as well as using client/login configuration scripts.
Well there's also the problem that basically zero clients do anything with it.
And exactly zero clients that can do anything with IPV6, what's your point? Basically zero is greater than exactly zero any day.
You don't think we need MX records? Hell I think you'd have a _HUGE_ problem getting rid of CNAMEs. I can sort of understand wanting SRV records for everything, but that's been around for a while too and hasn't exactly been taken up in droves.
I think we don't need, never needed, and never should have used MX records. I think CNAMEs are the bane of satan, and that DNS was designed by three monkeys trying to solve a four banana problem.
I also think that if we cannot get rid of MX records and CNAME records, we're never getting to anything even remotely close to IPV6.
Of course, I challenge the IETF to prove me wrong and actually provide a documented migration plan.
The article fails to address the most important issue of any piece of blogging software:
does it save any time
It seems to talk about all the problems you'll have (spam, configuration, administration, etc), and I appreciate that they skim the fact that having a managed blog means you don't have to deal with this shit.
does it save any time
Much blog software is yet another PHP application complete with image posts, modules and forums, and every bell and whistle, and that is just fine except normal people can't or don't want to use that. They want to be able to publish their thoughts and/or knowledge and not have it take a lot of their time to do so.
Many roll-your-own bloggers I know of spend a great deal of time with link and content spam, adjusting links, dealing with stupid textarea or HTMLArea junk, and heaven forbid they actually post any content.
IPV6 is being led by fools that are convinced that IPV6 is solely "a matter of time". Fact is, they have no transition plan, and until they do, they're going to continue to get laughed at.
I have recommended on numerous occasions that the simplest solution is to freeze the IANA and require TCP and UDP services publish their ports in DNS, and while we're at it, deprecate every record but NS, PTR, SRV and A. Make it a requirement right now.
Existing installations have it easy- they simply publish SRV records that contain the port numbers they already are using. New installations get to contact one less central authority about addressing, and at the rate that primary Internet vehicles (web browsers and email clients) are being deprecated for bugs, client deployment could be had in as little as 6 months.
You wouldn't need to add new configuration to your clients, and you wouldn't need to change anywhere near as much software as needs changing for IPV6. Best part: you'd increase the public internet address space by almost 16 bits- giving us almost 68,719,476,736 addresses or room for each person on the planet to publish 10 uniquely and immediately addressable services each - and that's without reallocating existing blocks- you do that and the number skyrockets to nearly 281,474,976,710,656 - which is enough addresses for everyone ON THE PLANET to publish 46,912 similarly immediately addressable services right now.
In contrast, IPV6 not only has to do all the work I suggest, but it has to replace every client and every server- regardless of whether or not they are going to benefit from the increased address space and complexity and they'll need to change the configuration files and configuration databases of those programs as well to accommodate the larger addresses.
But this will never happen: IPV6 is being run by people who think A6/DNAME records are a good idea.
Re:Ma Bell? Yo no entiendo - SHORT VERSION
on
Ma Bell is Back
·
· Score: 1
My long distance calling seems pretty cheap. Before the breakup, the best you could hope for was $0.25 a minute-- in 1984 dollars.
And in 1985, it was $0.35 a minute.
Doesn't it occur to you that the reason it's so cheap now is because of other reasons?
Re:Ma Bell? Yo no entiendo - SHORT VERSION
on
Ma Bell is Back
·
· Score: 3, Informative
Um no, BBN did packet switching first by building the Interface Message Processor. AT&T said it could not be done.
That quote is taken out of context so many times it's not even funny. What AT&T said couldn't be done was replacing the analog infrastructure with the digital one required for packet switching.
There are no digital circuits in my town, so I'd say that packet switching still hasn't replaced the analog infrastructure.
I'd never say that it won't happen, some day, but this quote occurred back in 1965 over 15 years after AT&T started experimenting with packet switched networks.
Re:Ma Bell? Yo no entiendo - SHORT VERSION
on
Ma Bell is Back
·
· Score: 5, Informative
Alexander Graham Bell -> American Bell -> American Telephone and Telegraph (AT&T) + Western Electric -> Bell Laboratories (Bell Labs).
Bell Labs did everything first: telephones, lasers, telecommunications satellites, electronic and packet switching, UNIX, etc.
In 1949 Bell Labs was sued for antitrust. They settled in 1956 with the US DOJ. Part of the settlement is that Bell Laboratories couldn't use one monopoly (telephone) to gain others. In 1974 they got another antitrust suit which was to be split up in 1984.
Prior to 1984, there was one telephone company. The bell. Mother bell. Ma Bell. Whatever you like. It was so huge and spanned so many products and etc, that many people didn't know where one part began and another ended. They kept telephone and data circuit prices real high, so the DOJ's decision to make a bunch of little bells (baby bells) was to make it easier for others to compete and hopefully bring the prices down.
Write the overloading implementation as a series of proofs for interested field so that people can't make shit like << mean anything other than left-shift (multiply by power of two).
For example, to overload "==" make the software implement a routine "comparitor" that returns a structure of public elements that the runtime resolves as comparison itself. To implement String's comparitor, have it return a structure like this: { int; byte[]; }
The result is that the compiler can figure out how to compare that and implement !=, ==, >, >=, <, <= all from one little statement.
To overload arithmatic operations like "+" again, resolve to a graph structure that the compiler can perform sumation on, then a routine that returns that graph structure to the desired (returned) object.
By making overloading this painful, nobody will do it EXCEPT in the one place where it can actually help- things that model numbers. That's because it won't seem like a shiny piece of plastic that programmers can implement in all their classes.
True story:
A CS postgraduate(!) I'm aware of uses C++ like it's going out of style. Every class he implements (which is perfectly documented, I'm sure) overloads every single operator so that they will all have SOME semantic meaning- even if that meaning is to cause the program to die a horrible death.
Unfortunately, the end result is that a language as flexible as C++ produces things like dialects that only those trained in those dialects can work with it. They might be wonderful C++ programmers, but completely incapable of dealing with this code because it's just so different.
String+String is as stupid as FooBazString. It DOES add confusion, and doesn't buy a damn thing. While I am sick of BigNum.add() operations, if that's what is needed to keep these kids from making another pile of shit like C++, then that's what I'll need to use.
There is no way anyone can wrap my head around 60,000 equally accessible and - as far as the computer is concerned- equally relevant system calls.
With technologies like "Intellisense" (or the EMACS scratch buffer, or your other local system equivilent- no it wasn't invented here fanboys), you don't have to.
In contrast, POSIX has relatively few APIs layered underneither relatively few more. Across all the "common" APIs you'll find on a modern Linux system, you'll probably find just about as many as you'll find on Windows.
However, you'll note that many POSIX programmers refuse to use things like Intellisense (or whathaveyou) for these purposes- not just because they rot the brain (that's something we find out the hard way as well) but because it simply isn't necessary(!)
I'm almost positive GNOME offers perfectly usable functions somewhere that allow me to put up struts, but I have never used them. Oh I think I went looking for them once, but I didn't look long because once I found GDK_WINDOW_XID() I was back in X11 land.
Because my knowledge is layered as well, this means that building my application for a platform or environment I don't normally target means that I don't have to learn everything at once. I'm happy to use the normal file I/O operations I use everywhere when I cannot quite figure out the glib way to do it, and so it is I should!
The win32 development model doesn't make this so easy- APIs are all at the same level (do I want GetDriveType or SetupDlGetDeviceRegistryProperty?), change meaning (e.g. MoveFile working differently on WinME and Win2K), and sometimes completely defying documentation (SqlDataReader.GetChar?) and so on. Worse still, by making all API available equally how is the programmer to function?
As a result, methodologies that I have used for several decades now are completely inappropriate- I may be able to write a ActiveX control in C, but I certainly would never want to! Not only will Windows dictate your resource files, dialog boxes, and programming structure, but it'll also dictate your programming language as well!
Enough is enough!
There are plenty of tasks that are a pleasure to code in perl. Others that Objective-C makes for more fun. Still others I might find a use for Java or even C#, and yet I haven't found any on their own merits that would demand C++ other than the IMAPI* family of interfaces is grossly inaccessible to any other language.
The consequences are that I keep win32 development to the bare minimum and do not accept any win32 development jobs- and the result? I'm writing more code than I ever did before.
I'd like to ask anyone who actually enjoys writing software on Windows to tell me their secret. The development tools are lacking, and the APIs are daunting. I dare say the Win32 development environment is the absolute worst ever, so I tenatively question anyone who says otherwise: Have you ever used anything else? (Seriously. Take 30 minutes and write kiosk software in Objective-C and XCode. Take another 30 to see how good ol' GNUMakefiles can improve your life. It's absolutely amazing Win32 developers that see my methods to understand that they can work on sources instead of processes)
Slashdot Mirror
I'm not sure you've read the specs...
What gives you that idea?
Like all security, you need a trust-anchor root.
Wrong. You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be), not if you want to prove authority (that the resource is being generated by the correct host) or integrity (that the resource data hasn't been altered). Go read ISBN 0471117099 for practical algorithms if you like.
Meanwhile, existing attacks on DNS have involved subverting authority (by transferring names between nameservers without permission) and integrity (through cache poisoning) and not on identity (which DNSSEC spends considerable complexity on).
DNSsec is designed so that you can do offline signing of data.
Wrong. Check RFC 4033 sec 3.1: It breaks Dynamic DNS if you sign your data offline.
I couldn't understand your VER proposal at all
There's a lot you couldn't understand. Asking questions can often help solve that problem.
Ummmmm, I hate to do this - god I hate to do this, but I'm actually going to support MS on this one.
Ummmm, why?
I wrote Netscape 3 applications that performed asynchronous javascript very well- far better still even than Microsoft's broken MSXML control. There's no reason that they couldn't have been made to work with Netscape 2 (although not quite as transparently).
Five minutes of looking elsewhere in the comments of this news and you'll find others who have done it as well.
I mean, you weren't there, so what the fuck do you think gives you the right to write history about it?
Another word for "security early adopter" is fool.
DNSSEC is not secure because it doesn't address the fundimental issues with security and nameservers.
* It doesn't stop cache poisoning attacks- a client resquesting a name from a poisoned cache won't get the key so they won't know anything is wrong.
* Breaking the nameserver itself gives you the keys as the nameserver is required to sign the resource records, so in this case, it gives people a false sense of security that they don't have!
* Finally, as it stands, DNSSEC perscribes to give a particular company power that hasn't demonstrated that they're trustworthy enough to hold it. You can't get a DNSSEC certificate right now unless you make your own, and even one day, if someone will sign DNSSEC certificates (like Verisign), whos to say someone won't get them to sign a bogus certificate (HINT: Verisign was already convinced to sign a code-signing certificate for someone claiming to be Microsoft Corp- are we supposed to trust these people?)
A better option would be to record a new RR type, like "VER" which acts as a verifier for (all) other data- the result contains an indexed hash of every response the server can give and the whole shebang is signed by a key that's signed by the immediate parent of the zone. Timelimit it and you're CURRENTLY safer than anything DNSSEC offers. VER would not be generated by the DNS server itself, but would have to be updated periodically all the same. It would also be big, which would mean likely TCP connections...
A better option would be to continue using in-transport mechanisms like S/MIME, PGP, SSL, or SSH that are ALREADY DEPLOYED.
A better option would be to do away with all that is DNS and make something good.
But nowhere is it even an option to deploy something that doesn't do anything but MAYBE produce a false sense of security.
The jurors are supposed to and expected to vote based on the laws.
No they're not.
This is one of the biggest lies that Judges and Lawyers to this day try and convince jurors.
It's unfortunate that Judges aren't required to take an oath before instructing the Jury on legal matters.
Jurors are following the law - whether they or you know it or not, when they decide whether the Judge is being a cockhead, the law is stupid, or that dumb slut had it coming.
The jury is purely a finder of fact,
No they're not.
This is one of the biggest lies that Judges and Lawyers to this day try and convince jurors.
Jurors not only have the right, they have the duty to decide whether the Judge is being a cockhead, the law is stupid, or that dumb slut had it coming.
Next time you think Jurors are required to decide on facts, or don't have the ability to rewrite law from the box, I urge you to pay attention at the next Michael Jackson molostation case, or if ever OJ Simpson decides to remarry.
I misread these: as (blaming slashcode) instead of what you probably meant.
And I can't use exceptions because this is an embedded device where I can't afford the 2kB-per-stack-frame hit that enabling exceptions in gcc gives me.
I covered that: or you shouldn't be using C++...
Regarding stack overhead, have you heard of inline functions? You can still write good readable code and let the compiler do all the dirty work, thank you very much. You may not feel comfortable enough to take advantage of the compiler with your current skills, but maybe in another 10-20 years...
You're kidding right?
Let me guess, you also run everything with -funroll-loops, don't you?
It's the opposite, 10-20 years ago I was quite comfortable using gotos - before I learned the basic principles of good C programming, mainly how to avoid spaguetti programming and break down your code into smaller meaningful routines.
I'm so glad the Linux kernel developers are 10-20 years behind you then.
Goto doesn't produce spaghetti code- you do. That's the problem. If you want to blame it on goto, fine, but inlining functions far away from their exception handlers is still spaghetti code.
By the way, most C compilers don't avoid the stack operations when inlining- most of the time they can't- they simply avoid the call routine.
Real programmers know better than to do that.
You've either duplicated finalization code (by putting it before each return), or performed it in the calling function which would mean additional stack operations).
Your solution is either less readable or (much) slower.
Real programmers know that goto has it's purpose and don't hide from good tools. If you can't use goto properly, that's fine- maybe in another 10-20 years of programming you'll feel comfortable enough with your skills to use it.
That's fine, but I'd put "error:" after the return success. That way people aren't jumping backwards.
:) )
Of course, with C++, you really should be using C++ exceptions (or you shouldn't be using C++...
If fn2() takes several arguments, you've done extra stack operations. Your exception handling code is also far away from the code that generated the exception.
So it's slower and less readable...
It's slower and less readable (consider if "Do something useful" is quite long)
In general, I find it easy to follow as long as gotos always go the same direction (down)- and that we only have one or two labels in a function- we're fine.
Although, also in general, people who use gotos going up, or have more than two labels in their functions, or that otherwise avoid goto like it's some sort of plague tend to have other problems.
autopackage is probably the current best tool for this. It makes a single, easily installable (and removable) package while coercing my system's GCC and libs into versions that are suitable for other distributions.
:)
I use it currently for schism tracker (particularly the CVS builds that I do).
It works very well for me: Debian, Ubuntu, SUSE, Fedora, Gentoo, and Mandrake users have reported success with these binaries built with (gasp) a lone FC4 machine.
One day, I'll actually do a proper release and six years later it'll show up in the next Debian release. Then your fancy apt-get tools will work.
And to kneejerk jackasses that say "just release the source"- you must realize that the source is good for you and me (well me anyway, I cannot speak for you, obviously), the people who USE these programs have absolutely NO INTEREST in doing the work that I have just done for my own purposes.
Plus, having them use a single binary means that it's very easy to debug with nothing more than a core file.
Oh, and I suppose I am giving the submitter the benefit of the doubt that we are indeed talking about Free Software, aren't we?
Agreed. I do however, have a very different requirement:
I think it's important that I be allowed to fix my servers and workstations, and that I be allowed to redistribute my fixes as I see fit.
Microsoft however, doesn't think I should be allowed to fix my servers and workstations. They have even gone so far as to convince a very large number of people that it's illegal for me to do so.
Right now, it may not matter so much, but in the future, it's not going to be x86 and some APIs that matter, it's going to be Digital Restrictions Management (DRM), and with that, I won't be allowed to do the things that I presently take for granted (and anyone else who uses my software- often without realizing it) unless I manufacture my own motherboards.
In the meantime, I am completely opposed to MS, as a steady source of income for me as I consult and help people keep those machines running is very important to me.
I can understand if it's not important to you, but please don't confuse the issue. It's not about reliability, or some feature set, or even usability. It's freedom.
If that freedom didn't exist, Windows certainly wouldn't have anyone to compete with, and you'd we living with the reliable, interoperable, supported, reasonably well priced, configurable and flexible system that is Windows NT 4.0.
Maybe that appeals to you- after all, you'd be doing more reinstalls, and as a consultant that would mean more income. But don't even suggest for a moment that you're using the right tool for any job when you snub freedom.
I concede that you don't care what OS you're running, but I think your reasons why are deplorable.
Never mind the fact that one there are such things as dual-stack hosts and 6-over-4, making the transition gradual enough for most people not to notice... Never mind the fact that A6 records have been deprecated for more traditional AAAA records... Never mind the fact that we are at an early stage of a long transition (the official line, IIRC, is for universal IPv6 adoption by 2020 or so)...
I never mind the fact because it isn't: IPV4-in-IPV6 isn't a standard, the most popular sites on the internet aren't "dual-stack hosts", and the most important ones aren't either. I also never mind the fact that the BIND corporation doesn't know that A6 records have been deprecated, or that doomsday folks keep pointing out the end of IPV4 addresses in less than 10 years.
I'm glad that univeral IPV6 adoption is hoped for by the designers of IPV6 by 2020 or so, but they still haven't told us how. I mean, I realize they have 15 years to do it, but given the fact that they've pissed away the last 10 I don't have a lot of faith in them.
Fanboys such as yourself talking about how gradual the transition will be are seriously confused: There are hosts on the Internet that still haven't migrated to MX records, and those have been a standard for MORE THAN 15 years, so I fail to see why anyone might think we can get EVERY SINGLE COMPUTER OFF THE INTERNET when we still have hosts that don't comply with current Internet standards.
Arrrggghhh! Publishing services in DNS is full of problems. Replication delays, no TTL, no URL, etc. Why not use a protocol that was designed to register and locate services - Service Location Protocol (SLP).
Err, how about the fact that SLP doesn't work on the Internet?
I mean, I'm happy to suggest we move multicast onto the regular Internet, and use ICMP host names while we're at it, but given the fact that people setting MLTTL=30 will eat my downstream's network alive, I don't think SLP is really reasonable.
Also it has a problem that the choice is too simplistic, for instance there's only a place for one _webcache._tcp.and.org where most applications allow different caches for http, https and ftp ... plus exceptions.
The rest of the world solves part of that problem using split horizon and the fact that _httpproxy._tcp.example.org would be a perfectly adequate way to do it, as well as using client/login configuration scripts.
Well there's also the problem that basically zero clients do anything with it.
And exactly zero clients that can do anything with IPV6, what's your point? Basically zero is greater than exactly zero any day.
You don't think we need MX records? Hell I think you'd have a _HUGE_ problem getting rid of CNAMEs. I can sort of understand wanting SRV records for everything, but that's been around for a while too and hasn't exactly been taken up in droves.
I think we don't need, never needed, and never should have used MX records. I think CNAMEs are the bane of satan, and that DNS was designed by three monkeys trying to solve a four banana problem.
I also think that if we cannot get rid of MX records and CNAME records, we're never getting to anything even remotely close to IPV6.
Of course, I challenge the IETF to prove me wrong and actually provide a documented migration plan.
The article fails to address the most important issue of any piece of blogging software:
does it save any time
It seems to talk about all the problems you'll have (spam, configuration, administration, etc), and I appreciate that they skim the fact that having a managed blog means you don't have to deal with this shit.
does it save any time
Much blog software is yet another PHP application complete with image posts, modules and forums, and every bell and whistle, and that is just fine except normal people can't or don't want to use that. They want to be able to publish their thoughts and/or knowledge and not have it take a lot of their time to do so.
Many roll-your-own bloggers I know of spend a great deal of time with link and content spam, adjusting links, dealing with stupid textarea or HTMLArea junk, and heaven forbid they actually post any content.
does it save any time
If not, then I'm sticking to blogging with vi.
People don't seem to understand that IPV6 isn't the Internet. It's something else that nobody is on and nobody wants on because nobody is there.
http://cr.yp.to/djbdns/ipv6mess.html
IPV6 is being led by fools that are convinced that IPV6 is solely "a matter of time". Fact is, they have no transition plan, and until they do, they're going to continue to get laughed at.
I have recommended on numerous occasions that the simplest solution is to freeze the IANA and require TCP and UDP services publish their ports in DNS, and while we're at it, deprecate every record but NS, PTR, SRV and A. Make it a requirement right now.
Existing installations have it easy- they simply publish SRV records that contain the port numbers they already are using. New installations get to contact one less central authority about addressing, and at the rate that primary Internet vehicles (web browsers and email clients) are being deprecated for bugs, client deployment could be had in as little as 6 months.
You wouldn't need to add new configuration to your clients, and you wouldn't need to change anywhere near as much software as needs changing for IPV6. Best part: you'd increase the public internet address space by almost 16 bits- giving us almost 68,719,476,736 addresses or room for each person on the planet to publish 10 uniquely and immediately addressable services each - and that's without reallocating existing blocks- you do that and the number skyrockets to nearly 281,474,976,710,656 - which is enough addresses for everyone ON THE PLANET to publish 46,912 similarly immediately addressable services right now.
In contrast, IPV6 not only has to do all the work I suggest, but it has to replace every client and every server- regardless of whether or not they are going to benefit from the increased address space and complexity and they'll need to change the configuration files and configuration databases of those programs as well to accommodate the larger addresses.
But this will never happen: IPV6 is being run by people who think A6/DNAME records are a good idea.
My long distance calling seems pretty cheap. Before the breakup, the best you could hope for was $0.25 a minute-- in 1984 dollars.
And in 1985, it was $0.35 a minute.
Doesn't it occur to you that the reason it's so cheap now is because of other reasons?
Um no, BBN did packet switching first by building the Interface Message Processor. AT&T said it could not be done.
That quote is taken out of context so many times it's not even funny. What AT&T said couldn't be done was replacing the analog infrastructure with the digital one required for packet switching.
There are no digital circuits in my town, so I'd say that packet switching still hasn't replaced the analog infrastructure.
I'd never say that it won't happen, some day, but this quote occurred back in 1965 over 15 years after AT&T started experimenting with packet switched networks.
Alexander Graham Bell -> American Bell -> American Telephone and Telegraph (AT&T) + Western Electric -> Bell Laboratories (Bell Labs).
Bell Labs did everything first: telephones, lasers, telecommunications satellites, electronic and packet switching, UNIX, etc.
In 1949 Bell Labs was sued for antitrust. They settled in 1956 with the US DOJ. Part of the settlement is that Bell Laboratories couldn't use one monopoly (telephone) to gain others. In 1974 they got another antitrust suit which was to be split up in 1984.
Prior to 1984, there was one telephone company. The bell. Mother bell. Ma Bell. Whatever you like. It was so huge and spanned so many products and etc, that many people didn't know where one part began and another ended. They kept telephone and data circuit prices real high, so the DOJ's decision to make a bunch of little bells (baby bells) was to make it easier for others to compete and hopefully bring the prices down.
It didn't work.
Write the overloading implementation as a series of proofs for interested field so that people can't make shit like << mean anything other than left-shift (multiply by power of two).
For example, to overload "==" make the software implement a routine "comparitor" that returns a structure of public elements that the runtime resolves as comparison itself. To implement String's comparitor, have it return a structure like this: { int; byte[]; }
The result is that the compiler can figure out how to compare that and implement !=, ==, >, >=, <, <= all from one little statement.
To overload arithmatic operations like "+" again, resolve to a graph structure that the compiler can perform sumation on, then a routine that returns that graph structure to the desired (returned) object.
By making overloading this painful, nobody will do it EXCEPT in the one place where it can actually help- things that model numbers. That's because it won't seem like a shiny piece of plastic that programmers can implement in all their classes.
True story:
A CS postgraduate(!) I'm aware of uses C++ like it's going out of style. Every class he implements (which is perfectly documented, I'm sure) overloads every single operator so that they will all have SOME semantic meaning- even if that meaning is to cause the program to die a horrible death.
Unfortunately, the end result is that a language as flexible as C++ produces things like dialects that only those trained in those dialects can work with it. They might be wonderful C++ programmers, but completely incapable of dealing with this code because it's just so different.
String+String is as stupid as FooBazString. It DOES add confusion, and doesn't buy a damn thing. While I am sick of BigNum.add() operations, if that's what is needed to keep these kids from making another pile of shit like C++, then that's what I'll need to use.
What about us people who don't know what commands do what? Man pages are fairly useless if you don't know which command to ask for.
apropos?
On my system, I needed to find all the tools that involved mpeg operations because I simply didn't know, so I used:
$ apropos mpeg
and was greeted with:
SDL::MPEG (3pm) - a SDL perl extension
YUV4MPEG2 [yuv4mpeg] (5) - video stream format used by pipe-based
There is no way anyone can wrap my head around 60,000 equally accessible and - as far as the computer is concerned- equally relevant system calls.
With technologies like "Intellisense" (or the EMACS scratch buffer, or your other local system equivilent- no it wasn't invented here fanboys), you don't have to.
In contrast, POSIX has relatively few APIs layered underneither relatively few more. Across all the "common" APIs you'll find on a modern Linux system, you'll probably find just about as many as you'll find on Windows.
However, you'll note that many POSIX programmers refuse to use things like Intellisense (or whathaveyou) for these purposes- not just because they rot the brain (that's something we find out the hard way as well) but because it simply isn't necessary(!)
I'm almost positive GNOME offers perfectly usable functions somewhere that allow me to put up struts, but I have never used them. Oh I think I went looking for them once, but I didn't look long because once I found GDK_WINDOW_XID() I was back in X11 land.
Because my knowledge is layered as well, this means that building my application for a platform or environment I don't normally target means that I don't have to learn everything at once. I'm happy to use the normal file I/O operations I use everywhere when I cannot quite figure out the glib way to do it, and so it is I should!
The win32 development model doesn't make this so easy- APIs are all at the same level (do I want GetDriveType or SetupDlGetDeviceRegistryProperty?), change meaning (e.g. MoveFile working differently on WinME and Win2K), and sometimes completely defying documentation (SqlDataReader.GetChar?) and so on. Worse still, by making all API available equally how is the programmer to function?
As a result, methodologies that I have used for several decades now are completely inappropriate- I may be able to write a ActiveX control in C, but I certainly would never want to! Not only will Windows dictate your resource files, dialog boxes, and programming structure, but it'll also dictate your programming language as well!
Enough is enough!
There are plenty of tasks that are a pleasure to code in perl. Others that Objective-C makes for more fun. Still others I might find a use for Java or even C#, and yet I haven't found any on their own merits that would demand C++ other than the IMAPI* family of interfaces is grossly inaccessible to any other language.
The consequences are that I keep win32 development to the bare minimum and do not accept any win32 development jobs- and the result? I'm writing more code than I ever did before.
I'd like to ask anyone who actually enjoys writing software on Windows to tell me their secret. The development tools are lacking, and the APIs are daunting. I dare say the Win32 development environment is the absolute worst ever, so I tenatively question anyone who says otherwise: Have you ever used anything else? (Seriously. Take 30 minutes and write kiosk software in Objective-C and XCode. Take another 30 to see how good ol' GNUMakefiles can improve your life. It's absolutely amazing Win32 developers that see my methods to understand that they can work on sources instead of processes)