More to the point, Energy can be gotten from other sources besides oil. Whereas plastics (A medical revolution) may not be, and can be recycled.
A lot of plastics these days are not made from oil, but from natural gas.
My point is this. There will be higher priorities to use crude oil than energy because there are alternatives to produce said energy where there might not be in others.
There is nothing magical about oil, coal, or natural gas that can't be replicated industrially. For the most obvious examples, look up biodiesel, coal and biomass gasification, and methane-producing algae. We know how to get from biomass to whatever sort of hydrocarbon we want industrially, the only problem is that it is often energy-negative to do so rapidly from conveniently-available biomass. Given adequate energy, getting to plastics via biomass isn't hard, it is just not what anyone is doing now.
Well, yes, but for TCP you always have to guess 32 bits of sequence number, whereas for UDP spoofing control has to be implemented at the application layer level. In this case, DNS with sequential serial numbers, we're back to only 16 bits of TXID.
Plus 14 bits of port number (i.e. where in the 48k-64k range it is) and 32 bits of IP address. Really.
Think about it: if you have to guess at the transaction ID, that means that you are in a position where you can't see the stub resolver's queries, so you are also not seeing what IP those queries are being sent to or what source ports have been used. If an attacker can capture two stub resolver query packets (needed in order to know that they use sequential ports and know where in the 16k range they are currently) then that attacker should have no trouble capturing the query packet he actually wants to spoof a response to. In that circumstance there's need to guess at anything, there's only a need to reply faster than the real nameserver.
That is why Kaminsky, Vixie, and others have called this a flaw in the design of DNS. All anyone has ever needed to spoof a DNS reply is to see the query and answer fast. If an attacker knows what the query is, what nameserver IP it is directed at, and what IP+port the reply needs to go to, then there's only 16 bits of guesswork to do and that's not so hard. With a recursive resolver using a single port, an attacker can discover and deduce everything but the transaction ID without doing anything but getting the target to resolve some names, while that is simply not the case with a stub resolver.
O but as the article points out, Leopard clients are potentially exposed to a vulnerability that earlier OS X clients are not.
The Fleishman article in TidBITS says no such thing.
The SANS article it references notes that Tiger behaves identically
The cited behavior does not in fact amount to a vulnerability that is any worse than the vulnerability of a fully-patched system of any other sort, because without access to the path between the client and its recursing nameserver, an attacker would still be left guessing both the port and transaction ID
The Apple updates include a patched version of BIND for all 4 versions (standard and Server for both 10.4 and 10.5) but it is rather uncommon for non-server machines to be running BIND. Instead of having a local caching-only daemon running, they use the system's resolver library and the lookupd daemon that aggregates multiple name services and provides a unified cache (kinda like Solaris' nscd but not broken.) The system resolver uses ephemeral port numbers picked by the system for its DNS queries, and like all classic BSD systems, MacOS assigns ephemeral port numbers sequentially. This means that while Apple could have put port randomization into their libresolv, that would be a 2nd-rate solution. The right solution is to change the socket subsystem so that ports handed out when bind() is called with the port set to 0 are selected pseudo-randomly instead of sequentially. That change is easier said than done, and FreeBSD proved it a couple years ago. It looks like Apple decided not to push out that level of change fast or to hack up a temporary fix just for the resolver.
That's a perfectlyrational choice. The attack Kaminsky has described requires that the attacker trigger the target resolver to send DNS query packets to somewhere that the attacker can see them and hence find out the port number being used for queries. The canonical example of this is to have IMG tags on a web page pointing to a hostname resolved by a DNS server under the control of the attacker. That sort of approach is useless against the MacOS resolver, because it is a non-recursing stub. It only makes DNS queries to the recursive nameservers that it is configured to use, so it cannot be drawn into sending packets off to random bad guys for inspection. An attacker without a tap into the packet flow between the target and his nameservers has it just as hard as he would in attacking a patched nameserver. In addition, it may be that the lookupd cache that the stub resolver feeds may not be subtle enough to be vulnerable to the Kaminsky attack.
So, what's an ISP to do? Hmmm. Drop NNTP service. Saves you money and disk space. Claim it's to fight CP. Makes you look good to some people who don't know the real story. Customers who want Usenet then sign up with an NNTP service. They go over their bandwidth caps and you either then throttle them down or charge them extra bandwidth charges. They may pay, they may go elswhere. Either way, you've solved a few business problems for yourself, all the while being able to claim it's because you're thinking of the children.
You have hit the nail on the head. ISP's have been straining to do a halfway decent job in carrying the newsgroups that users want most (warez and porn) for years, and have been doing an increasingly poor job of it for a shrinking slice of their users while pouring more and more money down the rathole of disk, bandwidth, complex high-availability/synch architectures, and smart admins. Some (e.g. the SBC side of the 'new' ATT) have not carried the highest-volume groups for years with the lame excuses of piracy and/or kiddie porn. The push from Cuomo and NCMEC to drop alt.binaries.* is just what they need to validate a decision to drop a service that has made business sense for a long time. The external pressure lets them brush off user complaints and gives them a way to avoid suggestions of collusion with each other.
And from the control perspective, this actually may provide something useful for law enforcement. With ISP's operating free news servers for their customers and carrying the huge flood of binaries, Usenet is too big to really watch closely. With the shrinking universe of news servers that carry alt.binaries.* and the elimination of casual gawkers from the audience for "bad" binaries, it becomes easier for law enforcement to harvest a steady stream of serious kiddie porn fans. That is not actually useful for controlling the creation of kiddie porn, but it is a useful tool for law enforcement to maintain their PR and a sense of fear. There have been some people who have suggested that the most obvious kiddie porn posted in alt.binaries.* groups may well be law enforcement "bait" but one argument against that theory has always been that even if law enforcement was working with ISP's to track retrieval of those images, the population of targets is just too big and too rich with accidental viewers (i.e. casual news users whose filtering is done by eyeball) to be useful. With the users of the porn groups reduced to those willing to pay for them through a shrinking number of news specialist providers, baiting becomes a more feasible tactic.
WOW. Some moderator is an imbecile... The parent is not "insightful" in any comprehensible sense.
to the point:
FUCK?! Do the people that make laws have absolutely ANY idea how the internet works and is used? Are they even living on the same planet as the rest of us? Jesus. Fucking. Christ.
Anyone with more than half a clue about the net understands the basic principle:
My server, My rules.
That's a core premise of "how the Internet works" that I expect predates your lamented arrival and is indispensable to its continued operation. The law in question is not new and its enforcement is not new. Prosecutors have been very cautious about trying cases, but it has always been US law for as long as the Internet has existed that usage policies for Internet-connected systems are at least in principle backed by federal criminal penalties for violations.
Lori Drew should be on trial for 2nd degree murder of a child, but apparently the Missouri authorities didn't consider that possible for using MySpace as a weapon of psychological torture to drive a 13 year old girl to suicide.
Right... How many otherwise competent sysadmins do you know who can't C code? I've known plenty. Usually the good coders get jobs as coders, rather than as sysadmins.
That paragraph is a non sequitur.
There's a huge distinction between being a truly good programmer and being capable of hack/port/maintain/debug work in C. People who truly can't read C and do this sort of limited analysis are intrinsically no more than second-rate as sysadmins of any OS resembling Unix. That may offend some people, but it is a reality. Unix (and Linux and *BSD and MacOS X) are built on a C foundation that a sysadmin has to at least comprehend in order to handle well. A really good *[ui]x admin needs to understand C, and a good programmer has to undestand how real systems work.
If your sysadmins are failed coders, your sysadmins are shit.
If your coders are failed sysadmins, your coders are shit.
Of course, there are people who call themselves sysadmins because they can load Ubuntu, and there are also people who think that trusting whatever Sun/HP/RedHat/Apple/Debian tells them makes them sysadmins.
There are useful points in RFC1178, but some of it is obsolete or unscalable.
Important issues IMHO include:
1. Keep hostnames short. There's not much left technically these days that breaks on >8 characters even in places where mainframes survive, but humans need short names.
2. Use domains where they make sense, but don't go crazy with them. No one should have to remember more than a half-dozen subdomain names or more than one hierarchical level, i.e...one.universal.parent.domain is okay, but...parent.domain is going to be a major hassle.
3. Make the hostname expressive, but not obvious.
4. Avoid confusion between machines, even if you end up having to name a large number of machines with your scheme over many years.
5. Don't forget that in nearly all cases, you can give different audiences different names that make sense for them for the same machine without changing the machine's One True Hostname. In many cases, this is a very good thing to be doing because it is increasingly expected that a well-planned environment will allow for refactoring services among hosts, migrating services around without eliminating hosts.
To that end, I've become fond of schemes that make up a hostname with an 8-character name where the leading 3-5 are letters that carry usage and management meanings, and the remaining are digits identifying the particular host, so that a machine which changes function significantly might get a new name, but keep the same host number. The last one I used like this was working with an environment of a few hundred machines, so we had the luxury of 5 letters in the alphabetic part of the names. We mapped these to:
Physical location (i.e. which data center) OS Business-side owner (department or shared-use) General function (database, frontend web server, web app server, etc.) Support class (production, development, QA testing, sandbox testing, etc)
Because we had a lot of room in 3 digits, we also were able to encode more info into the high digit of the host number as well, so we could tell which of our networks a machine was on by "which hundred" the number was in. This scheme allowed us to do useful things in handling those machines without having to do much thought/research. Admins and even some users could tell what a machine was without looking it up in a database.
This is somewhere between the obscurity of using elements, astronomical names, or porn star names (I'm scared of anyone who could name 250 machines after porn stars...) and the invitation quality of using names like "fileserver-01" or "billing" that legitimate users should not need and intruders would appreciate. If you really must have user-friendly names, make them in addition to the canonical name for the host and segregate them into a distinct DNS zone.
Now that the source of the proof-of-concept is publicly available, we can expect that future trojans won't just politely request your password. Are you sure? After all, we are talking about *mac* users.:P
Let the flamewars begin!
The groundbreaking PoC for politely asking for authentication info was the Swen spamming worm. I've been seeing the result of Outlook Express users happily handing it their passwords for over 4 years, although the rate these days is just a trickle. People in general are a large enough set to follow Sturgeon's Law. Many will give their passwords to anyone who asks in conjunction with promising something positive.
Can you cite any examples of a case where a certificate has been subverted in this way?
Well, it was never made completely clear how Verisign screwed up in issuing two "Microsoft" certs for code signing (still X.509 certs) to the Wrong People back in 2001, but that is the canonical example of "legit" certs landing in the wrong hands and it helped spread better cert checking in browsers.
And while you are on your soapbox, what is the alternative? By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website, and that a dns record somewhere hasn't been subverted and I am instead entering my login details to a phishing site made up to look exactly like my bank?
I'm pretty sure you are talking out of your arse. Unless you can cite some examples of a big name company (eg a major bank) having had their certificate subverted in this way, and not having said certificate revoked almost immediately, i'll stick with what works thanks.
I don't think the poster you are responding to has an alternative solution. There isn't one. That does not mean that X.509 certs as they stand are really all that good. People turn off or weaken CRL checking and OCSP, CA's are selling server certs with effectively no identity checking, and it is in the business interest of all commercial CA's to have a market where there are a price differentiated range from cheap meaningless certs that say nothing valuable about identity to very expensive certs that can be argued to mean more. At that high end, the "EV" certs really are a bit more meaningful, but they are still open to compromise. The way revocation works and the way people set up their systems to use it, a working compromise could survive for days between the discovery of the compromise and the last time any browser is likely to use cached trust based on earlier checking for revocation.
Not so much a spiritual ancestor of ZFS as a direct descendent of the primary spur for the creation of ZFS: the Veritas Volume Manager and File System, now commonly referred to as the Veritas Storage Foundation, and owned by Symantec. Sun developed ZFS after years of varying cooperative/competitive relations with Veritas that were not really customer-positive. VxVM/VxFS is a nice combo, in that it offers all of those nice features and lets you do things like migrate device groups (which can contain many volumes) from one machine on a SAN to another almost as fast as a umount/mount. "Enterprise" Solaris admins love Veritas SF for what it does, but have never liked its licensing and support status. ZFS is Sun's way of finally offering a fully integrated enterprise storage stack so that they are no longer hostage to another company's strategic choices. That's particularly helpful since the Symantec purchase of Veritas.
it has snapshotting, intelligent striping and mirroring, dynamic resizing
Eh, exactly which feature is unique? Snapshotting, striping, mirroring, resizing, encryption, etc, all of it can be done through the device mapper stack.
AdvFS has a less concrete feature: maturity. It has been under development with the pressures of a commercial "enterprise" customer base for 16 years. Whether that maturity is going to be relevant in a port to other OS's is an open question.
I have situations where I don't want any filesystem at all on the mixed chunks (shared iSCSI block devices, for example), others where I want partial mirrors, parts crypted, parts remote-synced, etc. Mixing block device, volume management and filesystem together in my opinion, simply bad engineering. There are far too many assumptions about what people usually do so you end up with something suitable only for exactly what the designer had in mind, and worse, sometimes completely unsuitable for what people actually do.
Having run both AdvFS and ZFS, I _vastly_ prefer the layered approach of ext3/LVM/md/etc.
AdvFS is layered on top of a LVM, it just hasn't always been obvious that the two are not one thing. I have not worked with ZFS enough to know whether there really is severability between its layers, but I don't see where one would really want to make the cut for ZFS anyway.
That said, your general point is valid to some degree, in that one integrated stack of software to handle all storage devices and present a filesystem to apps isn't always the right choice, and well-defined layering can give you more flexibility for some uses. On the other hand, an integrated stack like AdvFS or ZFS (and to some degree IBM's JFS and VxVM/VxFS) can be a lot easier to manage for many situations.
Filesystems are one part of most systems where 'exciting' isn't the most desirable feature.
HP-UX isn't really relevant. AdvFS was a carpetbagger on HP-UX, not a native.
AdvFS comes out of the Digital side: OSF/1 aka Digital Unix aka Tru64.
It shares ancestry with Veritas Storage Foundation (aka VxVM+VxFS) roughly around Veritas 2.x, when Digital bought a license from Veritas in order to have their own tightly integrated file system and volume manager for OSF/1 on Alpha that couldn't be held hostage by the 800-lb gorillas of the time: the Sun+AT&T alliance and IBM. As such, AdvFS is very much like VxFS in structure, terminology, features, and even tool names, and shares most of its strengths.
ACTA is being negotiated in secret. A very bad practice. On the other hand, it is also being negotiated by an incompetent, generally scorned, lame duck administration with no "fast track" authority, so an opposition Congress will get to pick apart whatever they are sent and will be more inclined to do so for purely political reasons. The chances of ACTA actually being done any time soon are slim and none.
What was leaked is not a draft of the actual ACTA agreement or anything like it. It is four pages of vague suggestions of what someone (no one knows who) thinks should be in it.
Doctorow's description of what is in the leaked document makes it clear that he didn't bother actually reading it, but rather he seems to be channelling other people's conjecture about what might end up in ACTA when and if it actually becomes real.
Could someone please point me to where the info comes from that pre-publication editing broadly affects CDA 230 immunity?
The hallucinations of the article author?
Prior to CDA, US case law was converging on a problematic standard. It was looking like providers at all layers would be held legally responsible for defamatory or otherwise illegal content carried on their facilities if they practiced any prior restraint at all or if they engaged in ex post facto removal of content that was less than perfect, with a lot of fuzziness in how strong an editorial approach would trigger liability. Exercising editorial control of any sort opened providers to lawsuits over actions taken or not taken, because determining whether a provider was a "speaker" or "publisher" or "secondary publisher" would have to be determined by a trial of fact.
The point of the part of the CDA that became 47USC230(c) was to eliminate that problem and the endless litigation trap that the rest of the CDA would have created otherwise. Probably more important than part 2 was part 1:
(1) Treatment of publisher or speaker
No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider.
That effectively immunizes any service provider from being held responsible for defamation or obscenity someone else writes that they end up providing to their users, and it has no exceptions. Part 2 does have exceptions for actions not taken in good faith but having dabbled in bad faith editorial judgments doesn't kill the immunity given in part 1.
I'm sure people are going to go out and spend hundreds of dollars on garbage software that serves no other purpose just to be able to buy downloadable videos from WalMart.
That's simply not true. Modern IE is Windows-only. IE5 was the last version that had any non-Windows implementations. MS abandoned both the MacOS and Solaris versions years ago, leaving them full of holes that will never be fixed and non-functional on modern systems. Apple is shipping half a million Macs every month without IE and with no way to run IE without an emulator, virtual machine, or dual-boot setup.
You must remember that us techno-geeks don't make up a whole lot of marketshare.
This is true, but off-target. The Mac segment of the home computer population (which is significantly larger than the Linux segment or the Mac share of new sales) is not mostly "techno-geeks" at all. Depending on whose numbers you believe (and WM's internal numbers might be best for them...) the shunning of non-IE browsers locks out 7-20% of users completely, and they are generally a more affluent segment.
Of course, that does not mean the decision by WM is not smart business. They know all about market segmentation and how to focus on winnable games. The no-IE segment is messy and expensive to serve, and the biggest slice (Mac users) has a lock-in to the existing dominant player in commercial video download: Apple. There's also a problem with the content providers: they demand strong DRM and that is hard to provide without staying MS-only or being Apple.
That whole apple is making money from selling the iPod not the music has been proven false by people who read the Apple stock report and did not number crunching.
Apple makes its money from iTune sales the iPod sales are nothing compared to the profit from iTunes.
Utter bullshit. I can tell from your writing that English is not your first language (or even really your second) but that doesn't mean you have to tell lies in it.
Apple's total revenue last quarter was over $7B, which is more than the iTMS revenue for its entire history. The hardware is still high-margin (Apple routinely beats 25% gross margin overall) and iTMS margin low enough that in the current 10-Q Apple warns that gross margin could pbe pulled down by increased iTMS sales. Total iTMS sales for the past year were a bit over 1B songs after mtaking 3 years to hit the firrst billion, and the labels take all but a few pennies on each sale. Meanwhile they sold 21M ipods just last quarter, with an average price around $200 with that sweet 31% gross margin reported in their 10-Q. Anyone who cares about that question really should read the actual earnings report and do the real math, not just assume that any post on/. is truthful.
Still short of true drag and drop compatibility, but that's all Apples doing trying to tie iTunes and the iPod together (thus getting more market penetration for their ITMS).
That might make sense if the iTMS was a serious profit center. iTMS is a low-margin draw (maybe a true 'loss leader' when fully accounted...) for the masses that gets them to buy highly profitable iPods and to lock them into iPods for the long term. The path of least resistance is to get an iPod and use iTMS to buy songs/videos and to subscribe to podcasts. If you have a lot of iTMS music, you have a lot of music that will play in iTunes or on an iPod and won't go anywhere else unless you go hunting down methods that are explained on web pages that talk about legality and pirating and RIAA suits. It does not matter what the real legality of making liberated copies is so much as it matters how close the bulk of users are willing to come to the edge of consensus legality (where consensus includes the RIAA and MPAA) and engage in behavior that seems evasive to get to that edge.
Bottom line: The iTunes/iTMS/iPod tying is not about getting iTMS sales, it is about getting iPod sales. It works because Apple makes it intrinsic to their mediation between Big Media and users.
You can't just expect a company to decide to scrap exchange for something else.
Why not?
Because any company of a significant scale with anything resembling sane management and competent IT people looks before it leaps for changes that big, and will notice that replicating the useful features that the Exchange/Outlook combination provides with open source components is likely to be a major integration project and may involve a great deal of development as well. For a lot of small to medium companies that is in itself a dealbreaker: they are likely to have little or no development and systems integration expertise. They have a staff of MCSE's who know how to keep Exchange servers from falling over too hard too often. Any significant change means finding a hired gun to do the work and retraining support staff or maybe hiring more support staff with the right skills. AND disruption.
Then there's the problem of actually being able to replicate the user-side functionality with open source. I've not been able to find that, and I've been looking for a long time.
Slashdot Mirror
More to the point, Energy can be gotten from other sources besides oil. Whereas plastics (A medical revolution) may not be, and can be recycled.
A lot of plastics these days are not made from oil, but from natural gas.
My point is this. There will be higher priorities to use crude oil than energy because there are alternatives to produce said energy where there might not be in others.
There is nothing magical about oil, coal, or natural gas that can't be replicated industrially. For the most obvious examples, look up biodiesel, coal and biomass gasification, and methane-producing algae. We know how to get from biomass to whatever sort of hydrocarbon we want industrially, the only problem is that it is often energy-negative to do so rapidly from conveniently-available biomass. Given adequate energy, getting to plastics via biomass isn't hard, it is just not what anyone is doing now.
Well, yes, but for TCP you always have to guess 32 bits of sequence number, whereas for UDP spoofing control has to be implemented at the application layer level. In this case, DNS with sequential serial numbers, we're back to only 16 bits of TXID.
Plus 14 bits of port number (i.e. where in the 48k-64k range it is) and 32 bits of IP address. Really.
Think about it: if you have to guess at the transaction ID, that means that you are in a position where you can't see the stub resolver's queries, so you are also not seeing what IP those queries are being sent to or what source ports have been used. If an attacker can capture two stub resolver query packets (needed in order to know that they use sequential ports and know where in the 16k range they are currently) then that attacker should have no trouble capturing the query packet he actually wants to spoof a response to. In that circumstance there's need to guess at anything, there's only a need to reply faster than the real nameserver.
That is why Kaminsky, Vixie, and others have called this a flaw in the design of DNS. All anyone has ever needed to spoof a DNS reply is to see the query and answer fast. If an attacker knows what the query is, what nameserver IP it is directed at, and what IP+port the reply needs to go to, then there's only 16 bits of guesswork to do and that's not so hard. With a recursive resolver using a single port, an attacker can discover and deduce everything but the transaction ID without doing anything but getting the target to resolve some names, while that is simply not the case with a stub resolver.
O but as the article points out, Leopard clients are potentially exposed to a vulnerability that earlier OS X clients are not.
You know, the ISC should have fixed this issue in 2001.
ISC has nothing to do with the system stub resolver for MacOS.
The Apple updates include a patched version of BIND for all 4 versions (standard and Server for both 10.4 and 10.5) but it is rather uncommon for non-server machines to be running BIND. Instead of having a local caching-only daemon running, they use the system's resolver library and the lookupd daemon that aggregates multiple name services and provides a unified cache (kinda like Solaris' nscd but not broken.) The system resolver uses ephemeral port numbers picked by the system for its DNS queries, and like all classic BSD systems, MacOS assigns ephemeral port numbers sequentially. This means that while Apple could have put port randomization into their libresolv, that would be a 2nd-rate solution. The right solution is to change the socket subsystem so that ports handed out when bind() is called with the port set to 0 are selected pseudo-randomly instead of sequentially. That change is easier said than done, and FreeBSD proved it a couple years ago. It looks like Apple decided not to push out that level of change fast or to hack up a temporary fix just for the resolver.
That's a perfectlyrational choice. The attack Kaminsky has described requires that the attacker trigger the target resolver to send DNS query packets to somewhere that the attacker can see them and hence find out the port number being used for queries. The canonical example of this is to have IMG tags on a web page pointing to a hostname resolved by a DNS server under the control of the attacker. That sort of approach is useless against the MacOS resolver, because it is a non-recursing stub. It only makes DNS queries to the recursive nameservers that it is configured to use, so it cannot be drawn into sending packets off to random bad guys for inspection. An attacker without a tap into the packet flow between the target and his nameservers has it just as hard as he would in attacking a patched nameserver. In addition, it may be that the lookupd cache that the stub resolver feeds may not be subtle enough to be vulnerable to the Kaminsky attack.
So, what's an ISP to do? Hmmm. Drop NNTP service. Saves you money and disk space. Claim it's to fight CP. Makes you look good to some people who don't know the real story. Customers who want Usenet then sign up with an NNTP service. They go over their bandwidth caps and you either then throttle them down or charge them extra bandwidth charges. They may pay, they may go elswhere. Either way, you've solved a few business problems for yourself, all the while being able to claim it's because you're thinking of the children.
You have hit the nail on the head. ISP's have been straining to do a halfway decent job in carrying the newsgroups that users want most (warez and porn) for years, and have been doing an increasingly poor job of it for a shrinking slice of their users while pouring more and more money down the rathole of disk, bandwidth, complex high-availability/synch architectures, and smart admins. Some (e.g. the SBC side of the 'new' ATT) have not carried the highest-volume groups for years with the lame excuses of piracy and/or kiddie porn. The push from Cuomo and NCMEC to drop alt.binaries.* is just what they need to validate a decision to drop a service that has made business sense for a long time. The external pressure lets them brush off user complaints and gives them a way to avoid suggestions of collusion with each other.
And from the control perspective, this actually may provide something useful for law enforcement. With ISP's operating free news servers for their customers and carrying the huge flood of binaries, Usenet is too big to really watch closely. With the shrinking universe of news servers that carry alt.binaries.* and the elimination of casual gawkers from the audience for "bad" binaries, it becomes easier for law enforcement to harvest a steady stream of serious kiddie porn fans. That is not actually useful for controlling the creation of kiddie porn, but it is a useful tool for law enforcement to maintain their PR and a sense of fear. There have been some people who have suggested that the most obvious kiddie porn posted in alt.binaries.* groups may well be law enforcement "bait" but one argument against that theory has always been that even if law enforcement was working with ISP's to track retrieval of those images, the population of targets is just too big and too rich with accidental viewers (i.e. casual news users whose filtering is done by eyeball) to be useful. With the users of the porn groups reduced to those willing to pay for them through a shrinking number of news specialist providers, baiting becomes a more feasible tactic.
WOW. Some moderator is an imbecile... The parent is not "insightful" in any comprehensible sense.
to the point:
FUCK?! Do the people that make laws have absolutely ANY idea how the internet works and is used? Are they even living on the same planet as the rest of us? Jesus. Fucking. Christ.
Anyone with more than half a clue about the net understands the basic principle:
My server, My rules.
That's a core premise of "how the Internet works" that I expect predates your lamented arrival and is indispensable to its continued operation. The law in question is not new and its enforcement is not new. Prosecutors have been very cautious about trying cases, but it has always been US law for as long as the Internet has existed that usage policies for Internet-connected systems are at least in principle backed by federal criminal penalties for violations.
Lori Drew should be on trial for 2nd degree murder of a child, but apparently the Missouri authorities didn't consider that possible for using MySpace as a weapon of psychological torture to drive a 13 year old girl to suicide.
Right... How many otherwise competent sysadmins do you know who can't C code? I've known plenty. Usually the good coders get jobs as coders, rather than as sysadmins.
That paragraph is a non sequitur.
There's a huge distinction between being a truly good programmer and being capable of hack/port/maintain/debug work in C. People who truly can't read C and do this sort of limited analysis are intrinsically no more than second-rate as sysadmins of any OS resembling Unix. That may offend some people, but it is a reality. Unix (and Linux and *BSD and MacOS X) are built on a C foundation that a sysadmin has to at least comprehend in order to handle well. A really good *[ui]x admin needs to understand C, and a good programmer has to undestand how real systems work.
If your sysadmins are failed coders, your sysadmins are shit.
If your coders are failed sysadmins, your coders are shit.
The parent needs modding as "Funny"
Of course, there are people who call themselves sysadmins because they can load Ubuntu, and there are also people who think that trusting whatever Sun/HP/RedHat/Apple/Debian tells them makes them sysadmins.
THEY ARE WRONG
There are useful points in RFC1178, but some of it is obsolete or unscalable.
Important issues IMHO include:
1. Keep hostnames short. There's not much left technically these days that breaks on >8 characters even in places where mainframes survive, but humans need short names.
2. Use domains where they make sense, but don't go crazy with them. No one should have to remember more than a half-dozen subdomain names or more than one hierarchical level, i.e. ..one.universal.parent.domain is okay, but ...parent.domain is going to be a major hassle.
3. Make the hostname expressive, but not obvious.
4. Avoid confusion between machines, even if you end up having to name a large number of machines with your scheme over many years.
5. Don't forget that in nearly all cases, you can give different audiences different names that make sense for them for the same machine without changing the machine's One True Hostname. In many cases, this is a very good thing to be doing because it is increasingly expected that a well-planned environment will allow for refactoring services among hosts, migrating services around without eliminating hosts.
To that end, I've become fond of schemes that make up a hostname with an 8-character name where the leading 3-5 are letters that carry usage and management meanings, and the remaining are digits identifying the particular host, so that a machine which changes function significantly might get a new name, but keep the same host number. The last one I used like this was working with an environment of a few hundred machines, so we had the luxury of 5 letters in the alphabetic part of the names. We mapped these to:
Physical location (i.e. which data center)
OS
Business-side owner (department or shared-use)
General function (database, frontend web server, web app server, etc.)
Support class (production, development, QA testing, sandbox testing, etc)
Because we had a lot of room in 3 digits, we also were able to encode more info into the high digit of the host number as well, so we could tell which of our networks a machine was on by "which hundred" the number was in. This scheme allowed us to do useful things in handling those machines without having to do much thought/research. Admins and even some users could tell what a machine was without looking it up in a database.
This is somewhere between the obscurity of using elements, astronomical names, or porn star names (I'm scared of anyone who could name 250 machines after porn stars...) and the invitation quality of using names like "fileserver-01" or "billing" that legitimate users should not need and intruders would appreciate. If you really must have user-friendly names, make them in addition to the canonical name for the host and segregate them into a distinct DNS zone.
Let the flamewars begin!
The groundbreaking PoC for politely asking for authentication info was the Swen spamming worm. I've been seeing the result of Outlook Express users happily handing it their passwords for over 4 years, although the rate these days is just a trickle. People in general are a large enough set to follow Sturgeon's Law. Many will give their passwords to anyone who asks in conjunction with promising something positive.
Can you cite any examples of a case where a certificate has been subverted in this way?
Well, it was never made completely clear how Verisign screwed up in issuing two "Microsoft" certs for code signing (still X.509 certs) to the Wrong People back in 2001, but that is the canonical example of "legit" certs landing in the wrong hands and it helped spread better cert checking in browsers.
And while you are on your soapbox, what is the alternative? By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website, and that a dns record somewhere hasn't been subverted and I am instead entering my login details to a phishing site made up to look exactly like my bank?
I'm pretty sure you are talking out of your arse. Unless you can cite some examples of a big name company (eg a major bank) having had their certificate subverted in this way, and not having said certificate revoked almost immediately, i'll stick with what works thanks.
I don't think the poster you are responding to has an alternative solution. There isn't one. That does not mean that X.509 certs as they stand are really all that good. People turn off or weaken CRL checking and OCSP, CA's are selling server certs with effectively no identity checking, and it is in the business interest of all commercial CA's to have a market where there are a price differentiated range from cheap meaningless certs that say nothing valuable about identity to very expensive certs that can be argued to mean more. At that high end, the "EV" certs really are a bit more meaningful, but they are still open to compromise. The way revocation works and the way people set up their systems to use it, a working compromise could survive for days between the discovery of the compromise and the last time any browser is likely to use cached trust based on earlier checking for revocation.
I just had a quick glance through the wikipedia page on this filesystem http://en.wikipedia.org/wiki/AdvFS
and it seems to share a surprising number of features with ZFS
http://en.wikipedia.org/wiki/ZFS
For example, pools, snapshots etc.
Not so much a spiritual ancestor of ZFS as a direct descendent of the primary spur for the creation of ZFS: the Veritas Volume Manager and File System, now commonly referred to as the Veritas Storage Foundation, and owned by Symantec. Sun developed ZFS after years of varying cooperative/competitive relations with Veritas that were not really customer-positive. VxVM/VxFS is a nice combo, in that it offers all of those nice features and lets you do things like migrate device groups (which can contain many volumes) from one machine on a SAN to another almost as fast as a umount/mount. "Enterprise" Solaris admins love Veritas SF for what it does, but have never liked its licensing and support status. ZFS is Sun's way of finally offering a fully integrated enterprise storage stack so that they are no longer hostage to another company's strategic choices. That's particularly helpful since the Symantec purchase of Veritas.
it has snapshotting, intelligent striping and mirroring, dynamic resizing
Eh, exactly which feature is unique? Snapshotting, striping, mirroring, resizing, encryption, etc, all of it can be done through the device mapper stack.
AdvFS has a less concrete feature: maturity. It has been under development with the pressures of a commercial "enterprise" customer base for 16 years. Whether that maturity is going to be relevant in a port to other OS's is an open question.
I have situations where I don't want any filesystem at all on the mixed chunks (shared iSCSI block devices, for example), others where I want partial mirrors, parts crypted, parts remote-synced, etc. Mixing block device, volume management and filesystem together in my opinion, simply bad engineering. There are far too many assumptions about what people usually do so you end up with something suitable only for exactly what the designer had in mind, and worse, sometimes completely unsuitable for what people actually do.
Having run both AdvFS and ZFS, I _vastly_ prefer the layered approach of ext3/LVM/md/etc.
AdvFS is layered on top of a LVM, it just hasn't always been obvious that the two are not one thing. I have not worked with ZFS enough to know whether there really is severability between its layers, but I don't see where one would really want to make the cut for ZFS anyway.
That said, your general point is valid to some degree, in that one integrated stack of software to handle all storage devices and present a filesystem to apps isn't always the right choice, and well-defined layering can give you more flexibility for some uses. On the other hand, an integrated stack like AdvFS or ZFS (and to some degree IBM's JFS and VxVM/VxFS) can be a lot easier to manage for many situations.
Filesystems are one part of most systems where 'exciting' isn't the most desirable feature.
AMEN!
HP-UX isn't really relevant. AdvFS was a carpetbagger on HP-UX, not a native.
AdvFS comes out of the Digital side: OSF/1 aka Digital Unix aka Tru64.
It shares ancestry with Veritas Storage Foundation (aka VxVM+VxFS) roughly around Veritas 2.x, when Digital bought a license from Veritas in order to have their own tightly integrated file system and volume manager for OSF/1 on Alpha that couldn't be held hostage by the 800-lb gorillas of the time: the Sun+AT&T alliance and IBM. As such, AdvFS is very much like VxFS in structure, terminology, features, and even tool names, and shares most of its strengths.
Correction: the stupid fucking ever-changing /.visual presentation made it LOOK like a reply to a post about Canada.
Signs what? Did you bother to read anything more than the /. summary, quoting hysterical bullshit?
Gee, that makes so much sense as a reply to a post about Canada...
A deeper, less hysterical, and non-intellectually dishonest analysis than Doctorow's chicken-littling is at http://arstechnica.com/news.ars/post/20080602-the-real-acta-threat-its-not-ipod-scanning-border-guards.html
The hallucinations of the article author?
Prior to CDA, US case law was converging on a problematic standard. It was looking like providers at all layers would be held legally responsible for defamatory or otherwise illegal content carried on their facilities if they practiced any prior restraint at all or if they engaged in ex post facto removal of content that was less than perfect, with a lot of fuzziness in how strong an editorial approach would trigger liability. Exercising editorial control of any sort opened providers to lawsuits over actions taken or not taken, because determining whether a provider was a "speaker" or "publisher" or "secondary publisher" would have to be determined by a trial of fact.
The point of the part of the CDA that became 47USC230(c) was to eliminate that problem and the endless litigation trap that the rest of the CDA would have created otherwise. Probably more important than part 2 was part 1:
That effectively immunizes any service provider from being held responsible for defamation or obscenity someone else writes that they end up providing to their users, and it has no exceptions. Part 2 does have exceptions for actions not taken in good faith but having dabbled in bad faith editorial judgments doesn't kill the immunity given in part 1.
I'm sure people are going to go out and spend hundreds of dollars on garbage software that serves no other purpose just to be able to buy downloadable videos from WalMart.
That's simply not true. Modern IE is Windows-only. IE5 was the last version that had any non-Windows implementations. MS abandoned both the MacOS and Solaris versions years ago, leaving them full of holes that will never be fixed and non-functional on modern systems. Apple is shipping half a million Macs every month without IE and with no way to run IE without an emulator, virtual machine, or dual-boot setup.
This is true, but off-target. The Mac segment of the home computer population (which is significantly larger than the Linux segment or the Mac share of new sales) is not mostly "techno-geeks" at all. Depending on whose numbers you believe (and WM's internal numbers might be best for them...) the shunning of non-IE browsers locks out 7-20% of users completely, and they are generally a more affluent segment.
Of course, that does not mean the decision by WM is not smart business. They know all about market segmentation and how to focus on winnable games. The no-IE segment is messy and expensive to serve, and the biggest slice (Mac users) has a lock-in to the existing dominant player in commercial video download: Apple. There's also a problem with the content providers: they demand strong DRM and that is hard to provide without staying MS-only or being Apple.
Utter bullshit. I can tell from your writing that English is not your first language (or even really your second) but that doesn't mean you have to tell lies in it.
Apple's total revenue last quarter was over $7B, which is more than the iTMS revenue for its entire history. The hardware is still high-margin (Apple routinely beats 25% gross margin overall) and iTMS margin low enough that in the current 10-Q Apple warns that gross margin could pbe pulled down by increased iTMS sales. Total iTMS sales for the past year were a bit over 1B songs after mtaking 3 years to hit the firrst billion, and the labels take all but a few pennies on each sale. Meanwhile they sold 21M ipods just last quarter, with an average price around $200 with that sweet 31% gross margin reported in their 10-Q. Anyone who cares about that question really should read the actual earnings report and do the real math, not just assume that any post on /. is truthful.
That might make sense if the iTMS was a serious profit center. iTMS is a low-margin draw (maybe a true 'loss leader' when fully accounted...) for the masses that gets them to buy highly profitable iPods and to lock them into iPods for the long term. The path of least resistance is to get an iPod and use iTMS to buy songs/videos and to subscribe to podcasts. If you have a lot of iTMS music, you have a lot of music that will play in iTunes or on an iPod and won't go anywhere else unless you go hunting down methods that are explained on web pages that talk about legality and pirating and RIAA suits. It does not matter what the real legality of making liberated copies is so much as it matters how close the bulk of users are willing to come to the edge of consensus legality (where consensus includes the RIAA and MPAA) and engage in behavior that seems evasive to get to that edge.
Bottom line: The iTunes/iTMS/iPod tying is not about getting iTMS sales, it is about getting iPod sales. It works because Apple makes it intrinsic to their mediation between Big Media and users.
Because any company of a significant scale with anything resembling sane management and competent IT people looks before it leaps for changes that big, and will notice that replicating the useful features that the Exchange/Outlook combination provides with open source components is likely to be a major integration project and may involve a great deal of development as well. For a lot of small to medium companies that is in itself a dealbreaker: they are likely to have little or no development and systems integration expertise. They have a staff of MCSE's who know how to keep Exchange servers from falling over too hard too often. Any significant change means finding a hired gun to do the work and retraining support staff or maybe hiring more support staff with the right skills. AND disruption.
Then there's the problem of actually being able to replicate the user-side functionality with open source. I've not been able to find that, and I've been looking for a long time.