Yeah, that works fine except that when translating your crack-induced style to the normal form and back again screws up revision control diffs, thereby making them completely useless.
Crack-induced? Grasping at straws, are we?
If the best counter to chosing to put opening braces on a line by themselves, or to indent by a different number of spaces is to call it "crack-induced", then I fail to see why one style is necessarily better than another. Defering to a mob, likely to exert influence in an area smaller than that from which they will inherit code, is not justified by any reasonable measure. If one style is not "better" than another by some objective metric, then why chose it? Furthermore, why is it difficult to adapt to the style in a particular file? Perhaps it is because the mob is unable to cope with more than a single style and insists on restricting others the same way. This is folly, as they almost certainly will inherit code where they lack influence over the style, so the whole exercise is moot and a power trip.
That said, an argument can be made for a consistent publishing and source code repository style for locally generate code. You prettyprint to the repository style before you check in the first time, and every time after that, so revision control diffs do not break. This requires automated prettyprinting on checkout to a preferred style, but if reformatting to one's style of choice can not be automated, then it is likely quite odd (and this is the only deference to standard on this issue that I will admit).
god, I'd hate to work with a selfish arsehole like you
By the same token, I hate to work with a selfish mob that naively thinks that a common style in which to edit is necessary any better than any other reasonably structured one and that is likely to match what they inherit.
So we have a few possibilities. (a) We can put source through the formatter before we start editing and after we finish. (b) We can put an auto-formatter on the source repository. (c) We can get a team meeting and majority rules.
The first is labor intensive and prone to forgetfulness when someone just wants to put a few patches in. The second is a royally bad idea as what you are checking in is not what you were working on. Most of the time it won't be an issue most likely, but it breaks a fundamental source control rule: test before you commit. To put rigor back in, you have to make the code changes, test it, put it through the formatter, test again, and then commit. You don't want to format at the first step because you're still working on it in your own formatting choice. The only other choice is to test redundantly.
(a)A few patches generally do not justify reformatting, no. But, it's easy to automatically reformat on checkin and checkout, optionally, with most source code control systems worth their salt. Most developers I know do not care about the style of something to which they're making a minor change. The kicker comes when they have to add several dozen or hundred lines of code (a few functions) quickly. The new code is formatted how they like and reformatted on checkin.
(b) shouldn't be an issue: If the compiler cares about stylistic issues it's a bad compiler and too fragile to be trusted in general. Test before checkin catches the most common things that might "break the build" but you should still do regular builds out of the repository because it won't catch all. So, you're still covered.
(c)Majority rules is a bad idea when the majority of developers are inexperienced, as is usually the case. This is precisely what leads to crippling coding standards the run counter to effective development: Manager decided "majority rules" and the majority has chosen something crippled, which is then "etched in stone". It takes a wise manager to poll for concensus and "sanity check" it.
My point is that with consistency comes the enhanced ability to spot check code that others wrote (and that I wrote six months ago).
This presumes that most of the code reviewed, maintained, or adapted comes from people who followed a known standard. That is rarely the case over a full project lifecycle. At best, you can apply the standards to a subset of the code which, at first, will be most (if not all) of it, but will become a shrinking part of the code base over the project lifecycle: whole teams will be replaced and will inject their idea of a "better" coding standard.
Java is a bit different here, because the conventions are more bound to the use of the language (and Javadoc) than C or C++. So, it is much more likely that external contributions might already follow a defacto standard. The trouble starts when one foolishly thinks the same is true of other programming languages, or that it should be.
Again, there is no "right way", save that which might accidently arise by common convention, or langage "owner" decree. Far better to invest in tools that can reformat to the standard du jure when different styles become an issue. It's a job for machines, not people.
One area where such "standards" fail misserably is when one has clever table-driven programs. These really are internal implementation languages in their own right, albeit disguised, and generally benefit from styles related to their particular scoping rules. These might conflict with the general styles related to the "outer" language used for the program that ultimately interprets the tables. This is why any style guide should care about issues of scope and attribute rather than elements of a particular language.
Switching brace style is basically instantaneous for me. For most others, it may take part of a day. For the really slow ones, it may take a second day. In any case, it takes less time to learn to do this than it takes to use a formatter over and over again.
RSH>The worst part of coding standards is when they are so poorly thought out that they make it impossible or at least very difficult to write certain syntactically-valid programs.
I agree. To my mind, the only thing worse than no conventions are conventions that get in the way of effective development. Your polymorphism example seems particularly egregious. In order to prevent something similarly annoying, our documentation standard leverages javadoc, which since the 1.2 jdk, allows for the inheritance of method documentation. Our documentation standard further leverages a well-organized code base. You're allowed to refer to documentation in another class if it means your code is clearer and easier to understand.
This is the correct approach. However, for every one person that encourages that approach, there are at least four (in my 20+ year career) that don't and simply generate manual stylistic overhead requirements. At least half of those forbid the use of automated tools to make the task easier, "because they might be buggy", or "only match 95% what I dictate the standard to be". Again it's fine to have a code publishing standard, but folly to apply it at code editing time unless you want to and your editor supports it. But, I have seen shops with coding standards so capricious and arbitrary that no automatic pretty-printing tool supports them 100% and the person responsible be unwilling to adapt to something reasonably close that was supported by an automated tool.
Perhaps you are fortunate to not work in such a shop. Currently neither do I (thanks arbitrary deity-of-the-week). But I've seen them: code nazis with nothing better do do that to watch people type in editor windows and yell when you hit one space too many, or apply an automatic reindentation function.
RSH>People were meant to code, not worry about indentation-nazis.
Which is why the little effort I do put into that responsibility is in helping people configure their tools to support the conventions automatically. If you have to put a lot of effort into formatting conventions, you're using the wrong conventions and/or tools. Since you've obviously got your panties in a twist over the issue, I suggest you look into a better development environment.
My objection is amimed at shops that outlaw the use of such tools. Code Nazis I've met actively prevent the use of alternate development environment -- to the point of forbidding installation of emacs even if vi is the "standard editor" and is installed as well.
RSH>For all your code-nazi bluster, you're screwed when you decide to leverage some open source code that uses a different style and there's the possibility you might contribute your changes back to the official code base (you don't have to if you don't distribute your modified version). I suppose you can make "exceptions" for foreign code, but why shackle your own developers and not shackle outsiders?
Contributing to an outside project means you conform to that project's conventions...
Exactly! So, why not treat each individual as an outside project? Standardize on the output, but not the input. Frankly I don't want to work with people who can't adapt to an arbitrary stylistic convention: I'll maintain their code in their style, and they'll maintain mine in mine -- or reformat to and from the repository standard. You give greater deference to outside developers than to your own? Sounds like a power trip to me.
...A little self-awareness lets you conform to another project's non-formatting conventions at the same time.
This presumes that the local Code Nazi let you.
What conflict were you envisioning again? Arguments like yours call you out as a programmer in desperate need of personal growth and seasoning. If you want to work in a team environment, that is.
I specifically do not want to work in a team where others have difficulty with minor stylistic conventions. I've bee
You've just told me that despite the myriad choices and possibilities available in programming that you cannot adapt to a simple change in bracing style.
No.
I've said that because of the wide variety of formatting tools available to produce a "standard form", it should not be necessary for an individual to conform to an arbitrary standard.
More pointedly, how much should I repect a manager and coworkers who can not adapt to my style if I can adapt to theirs?. How do they adapt to foreign code which uses a different style? Reasonable stylistic differences should not matter.
There is an argument to be made for the format of the "official" version of the source code published to the repository. But, not one of the styles you suggest is inherently better than any of the others and enforcing manual adherence to any of them is simply a power trip -- you do it because you can, or to accomodate those who can't (or won't) adapt to trivially different variations.
If you twist the argument, and purport to produce a "published form" standard, then you need to address far greater issues than indentation depth and symbol naming conventions: how to break long code lines, what the precendence is between syntactic elements (to know where to break a long line first), etc. Ideally such a standard should cross language boundaries with relative ease.
Why not apply the same layout rules to function actual argument scope as to basic block scope as to array index scope (particlarly in languages that natively support multidimentional arrays), that is, have a rule for breaking up "lists of things separated by a common syntactic element, and delimited at either end with other syntactic elements"?
If your shop codes in C, C++, or C#, and you dictate that private members start with lower case names, and public members start with upper case names, what do you say about protected members, for example? Too many shops I've seen punt, and forbid their use simply because their internal standard didn't address them.
Ultimately, manual source code reformatting is a fool's errand because eventually you will inherit external code not formatted to your standard and will have to understand it and deal with it in the way you received it (so you can contribute or compare with changes in the official distribution tree). If you need to enforce a manual formatting standard, your team is not adaptable or disciplined enough to "do the right thing" on their own.
Just download a copy of indent or astyle and save yourself a lot of trouble.
If you reread my comment, that's esentially what I suggest for the published form of code in the source code repository.
The type of code-nazi to which I refer is the kind that would have people who used automated tools to do this fired (and yes, I've suffered briefly in such shops during hard times), and insist that people manually count spaces.
The idea is to produce such a layer of overhead that everyone looks "busy" without being productive.
It is well and good to have a sandard format that everyone agrees to read and represents the format in which source code is maintained in the source code repository.
However, when writing code, it is a real hinderance to be forced to format things in a manner to which one is not accustomed. You spend too much time worrying about how to indent large function call actual parameter lists, long chained pointer indirections (i.e. foo->bar->entryIndex].reference->lookup[lookupInde x * lookupIndexScale + lookupIndexOffset].Value), rather than coding.
The solution is to use a pretty printer program that is sophisticated enough to understand and generate the source repository form, and automatically reformat to the tastes of most developers.
People were meant to code, not worry about indentation-nazis.
The worst part of coding standards is when they are so poorly thought out that they make it impossible or at least very difficult to write certain syntactically-valid programs. This usually crops up when internal function documentation standards do not provide for non-fundemental types for parameters or require that their types be documented fully. It creates havoc with polymorphic impementations of different specific derived instances of an abstract base class: you have to repeat the function parameter type documentation over and over and over. Change the class and you have to update documentation in each implementation file. Code nazis I've encountered retort, "So? Don't use polymorphism. Newbie developers don't understand it anyway." The right answer is to encourage use of Javadoc, doxygen, or other tools to make the synchronization of code and internal documentation easier. C# supports this notion natively.
But no, instead Mr. Code Nazi effectively takes away one of the most powerful OO concepts because some weenies "don't understand". Tell the weenies to slog fries at the local burger joint until they get a clue.
The rules by which I like to code are (a) read anything formatted reasonably; (b) format new code I create any damn way I please (within reason -- I have to maintain it too); (c) defer to the style already present when maintaining legacy code.
For all your code-nazi bluster, you're screwed when you decide to leverage some open source code that uses a different style and there's the possibility you might contribute your changes back to the official code base (you don't have to if you don't distribute your modified version). I suppose you can make "exceptions" for foreign code, but why shackle your own developers and not shackle outsiders? Seams ass-backwards to me. (Of course, the real reason is "because I can and it makes my code-nazi job look important).
On the assumption that one can't copyright a title of an otherwise copyright work (presumably, extracting the title would be "fair use"), I see nothing wrong with simply titling a book with something that just so happens to be the name of a domain. By itself, the title "Katie.Com" does not strike me as a problem in the same way that a book about the history of Slashdot, titled "Slashdot.org" wouldn't be (and the subject isn't even the same in this case).
Trademark law doesn't appear to apply even if there were a trademark granted: a book about online preditors is not likely to be confused with a run-of-the-mill online business presense.
So, it appears that the issue here is not one of copyrights, trademarks, or patents. It isn't an intellectual property issue of any kind. That said, there may be a case for malice or at least negligence: would not a reasonable person assume that an internet-related book titled with a legitimate domain name drive traffic to that domain? And that the attention might be unwelcome given the kind of person likely to be encouraged to browse it? While NAL, as a layperson, I do think a case can be made for negligence. Dumb move.
Trying to hijack a domain, of course, raises the bar to malice and harassment. Dumber move.
But, let's for the moment consider the unintentional (which does not appear to be the case here) titling of a book as that of a valid domain name, driving some traffic there, that is not likely to come from a population of "undesirable browsers" (i.e. pedophiles). Say, for example, a book entied "JohnDoe.com" about a newbie's attempt to establish an anonymous, but visible presence on the 'net. Could the holder of the JohnDoe.com domain do anything if they could not demonstrate damages (assuming that they're not trying to be anonymous but visible and thus have their schtick usurped by the book)?
I doubt it.
That said, I do think that even if it were inadvertent (which I do not belive), it's a pretty dumb and unoriginal move on Penguin's part. Dumb, because of the potential legal liability, and unoriginal, because they could have picked so many other domain-like titles.
For example, what about "Katie...Com"? (Perhaps that's a bit too close and obscure at the same time). Or, "Katie, dotCommed"? You get the idea. Of course, for good measure, a disclaimer to the effect that "...except where noted, internet domains, email addresses, etc. are fictional and any resemblence to legitimate ones are unintentional" should probably be present for good measure. In such a case, Ms. Jones could chose to note on her site that it is not to be confused with the book. An inconvenience, perhaps, but the other alternative would be to have to show some kind on intent on the publisher's part to make the connection.
I do hope Ms. Jones gets compensation for the harassment and apparent extortion she appears to be enduring, in this particular case. Penguin has, so far, lost major karma in my book, though ultimately, the courts will have to pass judgement.
When we were looking at houses to buy last year, I asked the agent to give me the current resident's phone number so I could check for DSL. It was available, and we made an offer.
That's exactly what I did when I went looking for a house in the Seattle, WA area. When we narrowed down our choices to a few houses, we had our agent approach the seller's agent asking for permission to check if DSL service was available to that current number. In this area it is normal for sellers to be present when buyers view a house (though I find this somewhat awkward both as a buyer and as a seller and when selling do the prospective buyers and their agent the curtesy of leaving for 20-30 minutes). So, it is easy to ask, "Do you have DSL?" If they say "yes", we then put immediate DSL availability as a contingency in our offer. If they say no, we ask permission to use their current phone number to find out. We have never been refused, though we make it very clear that's the only reason we want the number, and are willing to produce a written statement on the spot to that effect. In fact, you don't need the whole phone number -- just enough to identify the CO: the NPA-NXX (area code and first three digits of the number), though most on-line lookup apps insist on all seven digits of the number.
Now, just because the current owners have DSL or can get DSL does not mean you can: sometimes more than one CO serves a particular residential area (at least in some parts of Canada -- not sure anout the U.S. and they do occasionally run out of lines. Still, it is encouraging.
Finally, though the telco droid generally won't tell you where DSL is available (generally because they just have a phone number to availability mapping application), you can find out what COs serve which areas with a bit of Googling. You can then find out which COs have deployed DSL. It used to be the case that you then had to know which ISPs had DSLAMs colocated in the CO's. DSL Reports is a good place to look for more information on this. These days, the telco generally rolls out DSL access and can backhaul to any ISP that offers DSL -- the difference relates to who owns the DSLAMs: the telco or ISP. If the telco owns the DSLAM you pay them separately from the ISP, unless the telco has subcontracted DSL package sales to that ISP (but this is usually for an "Intarweb" style service -- no static IP and no inbound connections permitted -- often what the telco offers directly when it acts as the ISP. It's the difference between a $30/month and an $80/month service. You generally have to contact the telco about "advanced data services" which are completely different from "Residential DSL" (this being Verizon-speak, for example).
If you do contact the telco's data service department, you'll often get far more friendly and useful information: which CO's are provisioned, etc. -- generally enough to get your ISP of choice to handle their end of things. Verizon was actually helpful here, in my case (though getting the link hot was delayed twice for a total of a two week extra wait over the 5 days initially promissed). (Setting up the particular long distance plans was another story: getting dinged $0.70/minute instead of $0.07/minute for calls to Soviet Canuckistan (Canada) was not fun).
What I have found is this: it appears that if you're willing to spend $40-$45 a month just for the DSLAM port and backhaul to your ISP, as opposed to the telco's resold $19.95 or $29.95 Intarweb DSL service, they seam much more interested in being helpful. The biggest headache I encountered in knowing which department I needed to contact within Verizon: local, long-distance, Intarweb DSL, and Advanced Data Services appear to be so separate from each other and uncoordinated. It took a while to find out, for example, that I should be speaking to the "Advanced Data Services" department instead of the "DSL saled droid" (who didn't even know of the Advanced Data Services department). In fact, it
My take is that I'll tolerate split infinitives (and other faux-pas, like dangling participles) in spoken English, but I wince when I see them in written form (except when the intent is to demonstrate the character's use of language, of course).
Yes, I know the "English isn't Latin" debate around split infinitives, but I also know that English is about the most irregular language out there, and extremely difficult for non-native speakers to learn well (Hmm, should I have written "...to welly learn?"), because of this. So, when I see a novel construction that adds nothing to what is being communicated, I question it's value.
Often such constructions help make longer sentences shorter, but also more ambiguous or harder to parse -- we don't realize it because they become idiomatic. "That's not something I'll put up with" is, admitedly, less awkward than "That's something up with which I shall not put." Even better: "That's something I won't accept." Best: "That's unacceptable." But, is the syntactic relaxation of permitting dangling participles worth the potential ambiguous constructions that now become possible (not that I can think of any out of hand)?
I know language evolves, but I am more comfortable with the introduction of new nouns and verbs than I am with changes in structure.
Just don't bring up constructions like "intensive purposes", "reason being", and "quote... unqote". (These should be "intents and purposes", "the reason is", and "quote... endquote".) Yes, we speak that way, often to save time and get our point across faster before we are cut off ("before the cutting of our response is in the offing", perhaps?), but the written word persists longer than the relevance of the quill used to draw it across parchment. It deserves a somewhat better presentation than that accorded to dying vocalizations.
Yes, but with growth of P2P networks, that may become moot. The one-sided client/server bias in the Internet is largely due to the need for a centralized, albeit distributed, directory service and the asymetrical nature of inbound and outbound connections.
Consider what is possible if you hack TCP/IP to permit opining an inbound connection with merely a TCP ACK with the right sequence number (which was published on a P2P network when you "open" the non-standard port). The first respondant to connect "wins" and you can spawn a session. To accept another one on the same port, you publish a new ACK sequence number. The downside is that inbound connections have to poll to connect, and this does not scale well -- breaking the sequence number space into "inbound" and "response" sequences can address this somewhat. This is meant as an example of how the TCP connection sequence can be made symetrical and not a definitive best way of doing so.
While it is easy for an ISP to filter inbound TCP SYN packets, ensuring outbound ACKs aren't really rogue connection iniatiators using this hacked protocol requires the ISP's filtering to suddenly become stateful (otherwise they can not know that it is a bonafide response).
The downside of a symetrical session-establishment protocol is, of course, the race between inbound and outbound connection attempts (think of the difference between picking up the phone to make vs. answer a call -- you don't know which one you're doing utill after you listen for dialtone or a surprised counterparty ("...but it didn't ring yet!?"). But, that can be overcome.
I dunno, with 1231 comments (including this one) and a couple of articles under my belt, and Excellent karma, I think I'll be here a while longer.
'Course, I could blow all that karma in one fell swoop, and have been known to write vitrolic rants against my former home country (i have, at least temporarily, escaped) of Soviet Canuckistan (which elicit an amusing war of mods between insightful, informative, and flamebait), but somehow I manage to balance political views with technical information.
Then again, if knowledge of who my present employer is were to leak (I have not updated my online resume in a while), Slashdotters might be far less charitable with me.
Though, their lowest grade of biz. service did not include QoS guarantees, so it wasn't a question of being on the wrong circuit (connected to redundant equipment, etc.) or anything.
Look, dammit! It's...to go boldly...,...have gone boldly...,...looked really cool... Is that too much to ask?
DAMN YOU and your infinitive splitting... I should have never watched Star Trek. Now I will forever be unable to forget what my English teachers tried to teach me -- them and their antiquated grammar rules and all.
When I looked for DSL service with a single static IP address, and no inbound port-blocking, or restrictive TOS (outbound traffic limits being O.K. if reasonable -- I just want to sink email for my domain, and occasionally SSH in from work), Verizon only provided such facilities as part of "business class service" for around US$90 a month.
Sigh. A bit more than the $80 I budgeted, but O.K., I'll bite.
They refused to sell me the service even though I was willing to pay for it.
Turns out I got a better deal taking their DSL link backhauled to Blarg! for around $10 less.
Of course, that's DSL, and the person here is stuck with Cable, and so probably won't have the chance to split access and service providers. Besides, I didn't know that Cable broadband providers even offered commercial-grade service.
Well, it's not the only option, but the alternatives (VPN/SSH via a friend) have a high suckage coefficient even though they might have that stick-it-to-"da man" smugness. Besides, depending on your TOS, they may be forbidden (yes, they might not be able to tell, but you shouldn't put yourself in a situation where you have to violate TOS).
I would suggest, though, that people who are moving scope out the ISP and broadband provider scene before they settle on a place. At least try to live somewhere where you can chose between cable (ugh!) and DSL (there are some good providers out there, even if the access lines from the "telco" (cough, customer non-service, cough) might be expensive.
This is espescially important if you are buying a home, and found the perfect one, but broadband availability sucks: "$20k off the offer for the house being in the unfashionable part of the internet".
Fedora? Simple?? Help me, then
on
Moving To Linux
·
· Score: 1
I looked into migrating to FC2 from a heavily patched RH 7.2 system... yeah, that old.
Both RH 7.2 and FC2 try to tweak device ownership on console login/logout, but ocassionally screw up (either that or using ctrl-alt-backspace to logout is not recommended -- I've been doing that since forever) device ownership -- they get "stuck" to some old console user -- perhaps because some process is still "logged in" to a console. With RH 7.2, this means that things like sound "stop working" for the new user (as the user does not have the necessary permissions to access the/dev/dsp and related devices). With FC2, you get hung at the desktop setup (at least running Gnone) after login.
I haven't been able to find any mention of this behaviour anywhere, or a recommended workaround.
In it there is a device that does everything for you (yes, even that) that's very much like the evolution of the modern cell phone. Interestingly, there's an underground society of poor people that can not afford to pay their Joymaker fees, and have to resort to that quaint alternative to electronic credit: cash, which is, of course, only used by such poor "untouchables", and thus accepted in only the grimiest of places. Without a working Joymaker, you literally can't communicate with anyone except face to face (and even then, it's a desensitized experience, execpt, perhaps, for "natural-flow girls"). Read the book. It's fun.
The second novel in "Bipohl", "Drunkard's Walk", is the better of the two, though, IMHO. Basically, people who solve a statistical riddle related to human populations get mysteriously driven to suicide. It turns out that the solution to the riddle involves accepting the premise that there are some people who do not die.
Actually, they're planar magnetics: the principle is that you take a conventional speaker's voice coil (which has significant mass, thus inertia, thus sluggish response to "recover") and stretch it out to a single wire. Bond this to a thin diaphram (kapton is common) and place it within a big, honking, magnetic field. Voila!
Such speakers tend to be on the low end, sensitivity-wise, volume depending on current (there's a limit before the wire catches fire or melts), and magnetic field strengh. Still, coupled with a good amp, they have amazingly flat, albeit a bit directional (which can actually sometimes be a good thing to help avoid undesirable echoes), response above 200 Hz or so, all the way to ultrasonics.
I've always wondered what one could do with this principle and neodymium iron boron magnets.
I know you were making a play on sneaker vs. speaker, but, for those interested, I bought a pair of
these which retail for far more than $1k. I spent around another $1k for this custom subwoofer made to order (not purchased via Ebay) to mate with them for my Home Theater/Audio room.
Well, I have purchased plenty of gear over Ebay, including a rather expensive pair of speakers for which I paid over US$1000.
The trick is to understand the risk.
For purchases of around $200 or less, the reputation of the seller, manner of shipping, payment, insurance, and general professionalism is usually enough to judge whether it is "safe". It's not worth soiling a rep over $200. Recent bad feedback is poison for an Ebayer.
However, for larger purchases, I prefer using a credit card that provides fraud protection, and if it is an individual that can't accept a credit card, either an escrow service acceptable to me, or cash on delivery works.
I purchased my speakers from an individual who was located (at the time) within 30 miles of me. Before bidding we had arranged that, should I be the high bidder, the speakers would be delivered, set up, tested, and payment made on the spot by certified cheque, upon my satisfaction that they were as advertised. The kicker was that I was willing to throw in an extra $70 for the delivery service -- that's what the shipping charges would have run, so it seamed fair.
To date, I have not been scammed on Ebay. I suppose it will happen at some point over a relatively small purchase. But, one has to weigh the risks against the convenience and rewards of an online auction system.
Ah yes, grasshopper: It is difficult to sell water when it rains. This is why one does not provide "online" access -- one provides "Internet" access.
You may get far less customers, but you probably get far more knowledgable ones. I wonder how your support costs compare to a telco that caters to the sheeple that flock over to "that thar internat thingy". Covet not the attention of morons for, while many in number and flush with coin, they will vex thine support staff.
Where the smaller ISP can shine is in providing superior and distinct services. For example, I sink my own email -- it's the primary reason I have a static IP address. Still, I like to have a backup MX somewhere that can cache mail when my inbound server is down for maintenance. Right now, the comnpany hosting my website provides this, but remote access is via POP. I fetchmail from them and let my local sendmail sort things out. IMAP-SSL would be better, but they don't provide it. Still, if you're at the end of a fixed DSL link and my traffic routes through your and the telco's switches, I could tolerate plain-text authentication to your servers. Remember when plain text PPP authentication over dial up was just fine? Same principle.
So, sell me backup MX services, DNS for my domain, maybe a caching NNTP service, and while you're at it, NTP would be real great. Heck, throw it all together and sell me a real "domain" package deal without raking me over the coals: despite having a personal "family" domain, I don't run a biz, don't have large amounts of outbound traffic, and don't need a domain cert for commerce. I don't want to pay per-email address: just cap my aggregate inbound (backup MX) mail spool. Oh, hey, sell me a local VoIP PSTN "hop on" number, and partner with one of the bigger VoIP carriers, reselling their service. Retail some SIP hardware, like APs, SIP phones, etc.
I think there's lots of services a smaller ISP can offer to make themselves attractive to a larger audience that do not involve large amounts of outbound traffic.
I gave Verizon every chance to sell me the service I wanted: 1.5Mx384k, one static IP address, no unreasonable monthly caps (yeah, so I downloaded Fedora Core 2 sources and binaries, so?), and the freedom to open any port I like that requires authentication (SSH, IMAP-SSL), and commonly used ports (like SMTP) to anyone. I'm willing to accept reasonable restrictions on the ports providing anonymous access -- i.e. "thou shalt not relay email!". So, Verizon, sell me.
Well, first they said that a static IP was only available for "business" service. O.K., how much? Well, it was about $10 a month more than I really wanted to spend ($90 as opposed to $80), but I could squeeze somewhere else - $10 is worth the hassle to not deal with separate DSL and ISP providers. You'd think it would be a slam dunk sale for their 'droid, right? Wrong. They won't sell "business DSL" (and this doesn't even include QoS commitments) to residential addresses. I tried. Fuck you, Verizon. Hello, Blarg!
The fact that people like me are willing to pay double for marginally upgraded services should send a message to telcos like Verizon. If they could provide the service I want at a price I'm willing to pay, I'd buy it from them. Still, they have no right to complain: I'm still paying them more for the pipe than I would for the pipe and service from them (albeit, somewhat crippled service).
So you're happy to pay twice as much for the basic service that you should have gotten in the first place?
It's questionable whether a free market could provide this level of service (essentially unmettered 1.5Mx384k DSL with a single static IP) for less. That I can get a degraded level of service for less isn't the question: I can -- I just don't want it.
Just about all non-Verizon ISPs charge around the $30 a month rate over and above the line charge for a static IP. Of course, if you go with the resold Verizon dynamic IP package, the whole thing can be bundled for around $25 or so. Verizon charges around $100 a month for it's "business class" service with a static IP and, interestingly, won't sell it to residential addresses (this is poor-man's biz. DSL, BTW, without any QoS or uptime guarantees). At leazst
Verizon competes with Comcast in the "crippled broadband" arena, so their crippled service pricing is somewhat capped by that limited competition. More exotic alternatives like satellite, and fixed wireless, are more expensive than $25 a month and generally require greater capital outlay. So, it stands to reason that $25 a month is a reasonable "rock bottom" estimate for the price of crippled service to be sold at a profit.
Against that, paying double for decent, uncapped, unfiltered service, with a static IP address is not unreasonable.
Would I like to pay less? Of course. Do I think I'm being gouged? No.
Verizon already restricts people using Verison DSL. SMTP traffic is filtered unless it goes through their server and if it does go through their server, you can only use a verison.net email address.
This is misleading. I have Verizon service (POTS and DSL) in Monroe, WA, and they don't touch my traffic and don't give a fig about what servers I run.
See I have DSL service from Verizon, but they are not my ISP, so I don't have to put up with assanine ToS. I get my internet connectivity from blarg.net. Verizon just provides the backhaul from the DSLAM to Blarg! And, to their credit, Blarg! doesn't use MTU-mangling PPPoE. Just one long virtual circuit private "electonic highway" onramp for me (well, a dedicated lane on that onramp, if you really want to push the analogy -- work with me here:-)). My "always on" connection is very much always on.
Verizon sucks rotten eggs, as far as serivce is concerned (took 'em forever to acknowledge that, yes, I had an international long distance plan, and no, my calls to Canuckistan were not to be billed at $0.75/minute), but I'm stuck with them as a telco. So, I subscribe to what little I can. In this case, that means just the data pipe from me to my ISP.
There is a bit of a downside, of course, and that is price. But, it is not unreasonable: instead of some $30 a month for neutered dynamic IP access, I pay them closer to $40 a month just for the pipe and another $35 a month or so to Blarg!. Static IP? No problem (well, it costs a bit extra, included in the above price). NATed hosts? No problem. Inbound SMTP? No problem (but don't relay please: the IP address is ours and we like to keep a clean anti-SPAM reputation). Inbound telnet? Hey, it's your security, do what you want. Sure. Inbound HTTP? It's your box you're Slashdotting, not ours.
Now, of course, there are a few things I shouldn't do that'd hurt Blarg!, like run a busy site at the end of a DSL link, but those kinds of things would be bad to me too. Still, no one is going to cut me off for opening up port 80 for a day or two of private testing.
So, yeah, sure, sell me a fatter cheaper pipe Verizon. If all you can do with a modest degree of competence is sell pipes, do that.
Slashdot Mirror
Crack-induced? Grasping at straws, are we?
If the best counter to chosing to put opening braces on a line by themselves, or to indent by a different number of spaces is to call it "crack-induced", then I fail to see why one style is necessarily better than another. Defering to a mob, likely to exert influence in an area smaller than that from which they will inherit code, is not justified by any reasonable measure. If one style is not "better" than another by some objective metric, then why chose it? Furthermore, why is it difficult to adapt to the style in a particular file? Perhaps it is because the mob is unable to cope with more than a single style and insists on restricting others the same way. This is folly, as they almost certainly will inherit code where they lack influence over the style, so the whole exercise is moot and a power trip.
That said, an argument can be made for a consistent publishing and source code repository style for locally generate code. You prettyprint to the repository style before you check in the first time, and every time after that, so revision control diffs do not break. This requires automated prettyprinting on checkout to a preferred style, but if reformatting to one's style of choice can not be automated, then it is likely quite odd (and this is the only deference to standard on this issue that I will admit).
god, I'd hate to work with a selfish arsehole like you
By the same token, I hate to work with a selfish mob that naively thinks that a common style in which to edit is necessary any better than any other reasonably structured one and that is likely to match what they inherit.
The first is labor intensive and prone to forgetfulness when someone just wants to put a few patches in. The second is a royally bad idea as what you are checking in is not what you were working on. Most of the time it won't be an issue most likely, but it breaks a fundamental source control rule: test before you commit. To put rigor back in, you have to make the code changes, test it, put it through the formatter, test again, and then commit. You don't want to format at the first step because you're still working on it in your own formatting choice. The only other choice is to test redundantly.
(a)A few patches generally do not justify reformatting, no. But, it's easy to automatically reformat on checkin and checkout, optionally, with most source code control systems worth their salt. Most developers I know do not care about the style of something to which they're making a minor change. The kicker comes when they have to add several dozen or hundred lines of code (a few functions) quickly. The new code is formatted how they like and reformatted on checkin.
(b) shouldn't be an issue: If the compiler cares about stylistic issues it's a bad compiler and too fragile to be trusted in general. Test before checkin catches the most common things that might "break the build" but you should still do regular builds out of the repository because it won't catch all. So, you're still covered.
(c)Majority rules is a bad idea when the majority of developers are inexperienced, as is usually the case. This is precisely what leads to crippling coding standards the run counter to effective development: Manager decided "majority rules" and the majority has chosen something crippled, which is then "etched in stone". It takes a wise manager to poll for concensus and "sanity check" it.
My point is that with consistency comes the enhanced ability to spot check code that others wrote (and that I wrote six months ago).
This presumes that most of the code reviewed, maintained, or adapted comes from people who followed a known standard. That is rarely the case over a full project lifecycle. At best, you can apply the standards to a subset of the code which, at first, will be most (if not all) of it, but will become a shrinking part of the code base over the project lifecycle: whole teams will be replaced and will inject their idea of a "better" coding standard.
Java is a bit different here, because the conventions are more bound to the use of the language (and Javadoc) than C or C++. So, it is much more likely that external contributions might already follow a defacto standard. The trouble starts when one foolishly thinks the same is true of other programming languages, or that it should be.
Again, there is no "right way", save that which might accidently arise by common convention, or langage "owner" decree. Far better to invest in tools that can reformat to the standard du jure when different styles become an issue. It's a job for machines, not people.
One area where such "standards" fail misserably is when one has clever table-driven programs. These really are internal implementation languages in their own right, albeit disguised, and generally benefit from styles related to their particular scoping rules. These might conflict with the general styles related to the "outer" language used for the program that ultimately interprets the tables. This is why any style guide should care about issues of scope and attribute rather than elements of a particular language.
Switching brace style is basically instantaneous for me. For most others, it may take part of a day. For the really slow ones, it may take a second day. In any case, it takes less time to learn to do this than it takes to use a formatter over and over again.
I agree. To my mind, the only thing worse than no conventions are conventions that get in the way of effective development. Your polymorphism example seems particularly egregious. In order to prevent something similarly annoying, our documentation standard leverages javadoc, which since the 1.2 jdk, allows for the inheritance of method documentation. Our documentation standard further leverages a well-organized code base. You're allowed to refer to documentation in another class if it means your code is clearer and easier to understand.
This is the correct approach. However, for every one person that encourages that approach, there are at least four (in my 20+ year career) that don't and simply generate manual stylistic overhead requirements. At least half of those forbid the use of automated tools to make the task easier, "because they might be buggy", or "only match 95% what I dictate the standard to be". Again it's fine to have a code publishing standard, but folly to apply it at code editing time unless you want to and your editor supports it. But, I have seen shops with coding standards so capricious and arbitrary that no automatic pretty-printing tool supports them 100% and the person responsible be unwilling to adapt to something reasonably close that was supported by an automated tool.
Perhaps you are fortunate to not work in such a shop. Currently neither do I (thanks arbitrary deity-of-the-week). But I've seen them: code nazis with nothing better do do that to watch people type in editor windows and yell when you hit one space too many, or apply an automatic reindentation function.
RSH>People were meant to code, not worry about indentation-nazis.
Which is why the little effort I do put into that responsibility is in helping people configure their tools to support the conventions automatically. If you have to put a lot of effort into formatting conventions, you're using the wrong conventions and/or tools. Since you've obviously got your panties in a twist over the issue, I suggest you look into a better development environment.
My objection is amimed at shops that outlaw the use of such tools. Code Nazis I've met actively prevent the use of alternate development environment -- to the point of forbidding installation of emacs even if vi is the "standard editor" and is installed as well.
RSH>For all your code-nazi bluster, you're screwed when you decide to leverage some open source code that uses a different style and there's the possibility you might contribute your changes back to the official code base (you don't have to if you don't distribute your modified version). I suppose you can make "exceptions" for foreign code, but why shackle your own developers and not shackle outsiders?
Contributing to an outside project means you conform to that project's conventions...
Exactly! So, why not treat each individual as an outside project? Standardize on the output, but not the input. Frankly I don't want to work with people who can't adapt to an arbitrary stylistic convention: I'll maintain their code in their style, and they'll maintain mine in mine -- or reformat to and from the repository standard. You give greater deference to outside developers than to your own? Sounds like a power trip to me.
This presumes that the local Code Nazi let you.
What conflict were you envisioning again? Arguments like yours call you out as a programmer in desperate need of personal growth and seasoning. If you want to work in a team environment, that is.
I specifically do not want to work in a team where others have difficulty with minor stylistic conventions. I've bee
No.
I've said that because of the wide variety of formatting tools available to produce a "standard form", it should not be necessary for an individual to conform to an arbitrary standard.
More pointedly, how much should I repect a manager and coworkers who can not adapt to my style if I can adapt to theirs?. How do they adapt to foreign code which uses a different style? Reasonable stylistic differences should not matter.
There is an argument to be made for the format of the "official" version of the source code published to the repository. But, not one of the styles you suggest is inherently better than any of the others and enforcing manual adherence to any of them is simply a power trip -- you do it because you can, or to accomodate those who can't (or won't) adapt to trivially different variations.
If you twist the argument, and purport to produce a "published form" standard, then you need to address far greater issues than indentation depth and symbol naming conventions: how to break long code lines, what the precendence is between syntactic elements (to know where to break a long line first), etc. Ideally such a standard should cross language boundaries with relative ease.
Why not apply the same layout rules to function actual argument scope as to basic block scope as to array index scope (particlarly in languages that natively support multidimentional arrays), that is, have a rule for breaking up "lists of things separated by a common syntactic element, and delimited at either end with other syntactic elements"?
If your shop codes in C, C++, or C#, and you dictate that private members start with lower case names, and public members start with upper case names, what do you say about protected members, for example? Too many shops I've seen punt, and forbid their use simply because their internal standard didn't address them.
Ultimately, manual source code reformatting is a fool's errand because eventually you will inherit external code not formatted to your standard and will have to understand it and deal with it in the way you received it (so you can contribute or compare with changes in the official distribution tree). If you need to enforce a manual formatting standard, your team is not adaptable or disciplined enough to "do the right thing" on their own.
If you reread my comment, that's esentially what I suggest for the published form of code in the source code repository.
The type of code-nazi to which I refer is the kind that would have people who used automated tools to do this fired (and yes, I've suffered briefly in such shops during hard times), and insist that people manually count spaces.
The idea is to produce such a layer of overhead that everyone looks "busy" without being productive.
It is well and good to have a sandard format that everyone agrees to read and represents the format in which source code is maintained in the source code repository.
However, when writing code, it is a real hinderance to be forced to format things in a manner to which one is not accustomed. You spend too much time worrying about how to indent large function call actual parameter lists, long chained pointer indirections (i.e. foo->bar->entryIndex].reference->lookup[lookupInde x * lookupIndexScale + lookupIndexOffset].Value), rather than coding.
The solution is to use a pretty printer program that is sophisticated enough to understand and generate the source repository form, and automatically reformat to the tastes of most developers.
People were meant to code, not worry about indentation-nazis.
The worst part of coding standards is when they are so poorly thought out that they make it impossible or at least very difficult to write certain syntactically-valid programs. This usually crops up when internal function documentation standards do not provide for non-fundemental types for parameters or require that their types be documented fully. It creates havoc with polymorphic impementations of different specific derived instances of an abstract base class: you have to repeat the function parameter type documentation over and over and over. Change the class and you have to update documentation in each implementation file. Code nazis I've encountered retort, "So? Don't use polymorphism. Newbie developers don't understand it anyway." The right answer is to encourage use of Javadoc, doxygen, or other tools to make the synchronization of code and internal documentation easier. C# supports this notion natively.
But no, instead Mr. Code Nazi effectively takes away one of the most powerful OO concepts because some weenies "don't understand". Tell the weenies to slog fries at the local burger joint until they get a clue.
The rules by which I like to code are (a) read anything formatted reasonably; (b) format new code I create any damn way I please (within reason -- I have to maintain it too); (c) defer to the style already present when maintaining legacy code.
For all your code-nazi bluster, you're screwed when you decide to leverage some open source code that uses a different style and there's the possibility you might contribute your changes back to the official code base (you don't have to if you don't distribute your modified version). I suppose you can make "exceptions" for foreign code, but why shackle your own developers and not shackle outsiders? Seams ass-backwards to me. (Of course, the real reason is "because I can and it makes my code-nazi job look important).
Trademark law doesn't appear to apply even if there were a trademark granted: a book about online preditors is not likely to be confused with a run-of-the-mill online business presense.
So, it appears that the issue here is not one of copyrights, trademarks, or patents. It isn't an intellectual property issue of any kind. That said, there may be a case for malice or at least negligence: would not a reasonable person assume that an internet-related book titled with a legitimate domain name drive traffic to that domain? And that the attention might be unwelcome given the kind of person likely to be encouraged to browse it? While NAL, as a layperson, I do think a case can be made for negligence. Dumb move.
Trying to hijack a domain, of course, raises the bar to malice and harassment. Dumber move.
But, let's for the moment consider the unintentional (which does not appear to be the case here) titling of a book as that of a valid domain name, driving some traffic there, that is not likely to come from a population of "undesirable browsers" (i.e. pedophiles). Say, for example, a book entied "JohnDoe.com" about a newbie's attempt to establish an anonymous, but visible presence on the 'net. Could the holder of the JohnDoe.com domain do anything if they could not demonstrate damages (assuming that they're not trying to be anonymous but visible and thus have their schtick usurped by the book)?
I doubt it.
That said, I do think that even if it were inadvertent (which I do not belive), it's a pretty dumb and unoriginal move on Penguin's part. Dumb, because of the potential legal liability, and unoriginal, because they could have picked so many other domain-like titles.
For example, what about "Katie...Com"? (Perhaps that's a bit too close and obscure at the same time). Or, "Katie, dotCommed"? You get the idea. Of course, for good measure, a disclaimer to the effect that "...except where noted, internet domains, email addresses, etc. are fictional and any resemblence to legitimate ones are unintentional" should probably be present for good measure. In such a case, Ms. Jones could chose to note on her site that it is not to be confused with the book. An inconvenience, perhaps, but the other alternative would be to have to show some kind on intent on the publisher's part to make the connection.
I do hope Ms. Jones gets compensation for the harassment and apparent extortion she appears to be enduring, in this particular case. Penguin has, so far, lost major karma in my book, though ultimately, the courts will have to pass judgement.
That's exactly what I did when I went looking for a house in the Seattle, WA area. When we narrowed down our choices to a few houses, we had our agent approach the seller's agent asking for permission to check if DSL service was available to that current number. In this area it is normal for sellers to be present when buyers view a house (though I find this somewhat awkward both as a buyer and as a seller and when selling do the prospective buyers and their agent the curtesy of leaving for 20-30 minutes). So, it is easy to ask, "Do you have DSL?" If they say "yes", we then put immediate DSL availability as a contingency in our offer. If they say no, we ask permission to use their current phone number to find out. We have never been refused, though we make it very clear that's the only reason we want the number, and are willing to produce a written statement on the spot to that effect. In fact, you don't need the whole phone number -- just enough to identify the CO: the NPA-NXX (area code and first three digits of the number), though most on-line lookup apps insist on all seven digits of the number.
Now, just because the current owners have DSL or can get DSL does not mean you can: sometimes more than one CO serves a particular residential area (at least in some parts of Canada -- not sure anout the U.S. and they do occasionally run out of lines. Still, it is encouraging.
Finally, though the telco droid generally won't tell you where DSL is available (generally because they just have a phone number to availability mapping application), you can find out what COs serve which areas with a bit of Googling. You can then find out which COs have deployed DSL. It used to be the case that you then had to know which ISPs had DSLAMs colocated in the CO's. DSL Reports is a good place to look for more information on this. These days, the telco generally rolls out DSL access and can backhaul to any ISP that offers DSL -- the difference relates to who owns the DSLAMs: the telco or ISP. If the telco owns the DSLAM you pay them separately from the ISP, unless the telco has subcontracted DSL package sales to that ISP (but this is usually for an "Intarweb" style service -- no static IP and no inbound connections permitted -- often what the telco offers directly when it acts as the ISP. It's the difference between a $30/month and an $80/month service. You generally have to contact the telco about "advanced data services" which are completely different from "Residential DSL" (this being Verizon-speak, for example).
If you do contact the telco's data service department, you'll often get far more friendly and useful information: which CO's are provisioned, etc. -- generally enough to get your ISP of choice to handle their end of things. Verizon was actually helpful here, in my case (though getting the link hot was delayed twice for a total of a two week extra wait over the 5 days initially promissed). (Setting up the particular long distance plans was another story: getting dinged $0.70/minute instead of $0.07/minute for calls to Soviet Canuckistan (Canada) was not fun).
What I have found is this: it appears that if you're willing to spend $40-$45 a month just for the DSLAM port and backhaul to your ISP, as opposed to the telco's resold $19.95 or $29.95 Intarweb DSL service, they seam much more interested in being helpful. The biggest headache I encountered in knowing which department I needed to contact within Verizon: local, long-distance, Intarweb DSL, and Advanced Data Services appear to be so separate from each other and uncoordinated. It took a while to find out, for example, that I should be speaking to the "Advanced Data Services" department instead of the "DSL saled droid" (who didn't even know of the Advanced Data Services department). In fact, it
Yes, I know the "English isn't Latin" debate around split infinitives, but I also know that English is about the most irregular language out there, and extremely difficult for non-native speakers to learn well (Hmm, should I have written "...to welly learn?"), because of this. So, when I see a novel construction that adds nothing to what is being communicated, I question it's value.
Often such constructions help make longer sentences shorter, but also more ambiguous or harder to parse -- we don't realize it because they become idiomatic. "That's not something I'll put up with" is, admitedly, less awkward than "That's something up with which I shall not put." Even better: "That's something I won't accept." Best: "That's unacceptable." But, is the syntactic relaxation of permitting dangling participles worth the potential ambiguous constructions that now become possible (not that I can think of any out of hand)?
I know language evolves, but I am more comfortable with the introduction of new nouns and verbs than I am with changes in structure.
Just don't bring up constructions like "intensive purposes", "reason being", and "quote... unqote". (These should be "intents and purposes", "the reason is", and "quote... endquote".) Yes, we speak that way, often to save time and get our point across faster before we are cut off ("before the cutting of our response is in the offing", perhaps?), but the written word persists longer than the relevance of the quill used to draw it across parchment. It deserves a somewhat better presentation than that accorded to dying vocalizations.
Consider what is possible if you hack TCP/IP to permit opining an inbound connection with merely a TCP ACK with the right sequence number (which was published on a P2P network when you "open" the non-standard port). The first respondant to connect "wins" and you can spawn a session. To accept another one on the same port, you publish a new ACK sequence number. The downside is that inbound connections have to poll to connect, and this does not scale well -- breaking the sequence number space into "inbound" and "response" sequences can address this somewhat. This is meant as an example of how the TCP connection sequence can be made symetrical and not a definitive best way of doing so.
While it is easy for an ISP to filter inbound TCP SYN packets, ensuring outbound ACKs aren't really rogue connection iniatiators using this hacked protocol requires the ISP's filtering to suddenly become stateful (otherwise they can not know that it is a bonafide response).
The downside of a symetrical session-establishment protocol is, of course, the race between inbound and outbound connection attempts (think of the difference between picking up the phone to make vs. answer a call -- you don't know which one you're doing utill after you listen for dialtone or a surprised counterparty ("...but it didn't ring yet!?"). But, that can be overcome.
'Course, I could blow all that karma in one fell swoop, and have been known to write vitrolic rants against my former home country (i have, at least temporarily, escaped) of Soviet Canuckistan (which elicit an amusing war of mods between insightful, informative, and flamebait), but somehow I manage to balance political views with technical information.
Then again, if knowledge of who my present employer is were to leak (I have not updated my online resume in a while), Slashdotters might be far less charitable with me.
Though, their lowest grade of biz. service did not include QoS guarantees, so it wasn't a question of being on the wrong circuit (connected to redundant equipment, etc.) or anything.
"really looked"? ... "REALLY LOOKED"?!
Like "boldly gone"?
Look, dammit! It's ...to go boldly..., ...have gone boldly..., ...looked really cool... Is that too much to ask?
DAMN YOU and your infinitive splitting... I should have never watched Star Trek. Now I will forever be unable to forget what my English teachers tried to teach me -- them and their antiquated grammar rules and all.
Sigh. A bit more than the $80 I budgeted, but O.K., I'll bite.
They refused to sell me the service even though I was willing to pay for it.
Turns out I got a better deal taking their DSL link backhauled to Blarg! for around $10 less.
Of course, that's DSL, and the person here is stuck with Cable, and so probably won't have the chance to split access and service providers. Besides, I didn't know that Cable broadband providers even offered commercial-grade service.
I would suggest, though, that people who are moving scope out the ISP and broadband provider scene before they settle on a place. At least try to live somewhere where you can chose between cable (ugh!) and DSL (there are some good providers out there, even if the access lines from the "telco" (cough, customer non-service, cough) might be expensive.
This is espescially important if you are buying a home, and found the perfect one, but broadband availability sucks: "$20k off the offer for the house being in the unfashionable part of the internet".
Both RH 7.2 and FC2 try to tweak device ownership on console login/logout, but ocassionally screw up (either that or using ctrl-alt-backspace to logout is not recommended -- I've been doing that since forever) device ownership -- they get "stuck" to some old console user -- perhaps because some process is still "logged in" to a console. With RH 7.2, this means that things like sound "stop working" for the new user (as the user does not have the necessary permissions to access the /dev/dsp and related devices). With FC2, you get hung at the desktop setup (at least running Gnone) after login.
I haven't been able to find any mention of this behaviour anywhere, or a recommended workaround.
In it there is a device that does everything for you (yes, even that) that's very much like the evolution of the modern cell phone. Interestingly, there's an underground society of poor people that can not afford to pay their Joymaker fees, and have to resort to that quaint alternative to electronic credit: cash, which is, of course, only used by such poor "untouchables", and thus accepted in only the grimiest of places. Without a working Joymaker, you literally can't communicate with anyone except face to face (and even then, it's a desensitized experience, execpt, perhaps, for "natural-flow girls"). Read the book. It's fun.
The second novel in "Bipohl", "Drunkard's Walk", is the better of the two, though, IMHO. Basically, people who solve a statistical riddle related to human populations get mysteriously driven to suicide. It turns out that the solution to the riddle involves accepting the premise that there are some people who do not die.
Such speakers tend to be on the low end, sensitivity-wise, volume depending on current (there's a limit before the wire catches fire or melts), and magnetic field strengh. Still, coupled with a good amp, they have amazingly flat, albeit a bit directional (which can actually sometimes be a good thing to help avoid undesirable echoes), response above 200 Hz or so, all the way to ultrasonics.
I've always wondered what one could do with this principle and neodymium iron boron magnets.
I know you were making a play on sneaker vs. speaker, but, for those interested, I bought a pair of these which retail for far more than $1k. I spent around another $1k for this custom subwoofer made to order (not purchased via Ebay) to mate with them for my Home Theater/Audio room.
The trick is to understand the risk.
For purchases of around $200 or less, the reputation of the seller, manner of shipping, payment, insurance, and general professionalism is usually enough to judge whether it is "safe". It's not worth soiling a rep over $200. Recent bad feedback is poison for an Ebayer.
However, for larger purchases, I prefer using a credit card that provides fraud protection, and if it is an individual that can't accept a credit card, either an escrow service acceptable to me, or cash on delivery works.
I purchased my speakers from an individual who was located (at the time) within 30 miles of me. Before bidding we had arranged that, should I be the high bidder, the speakers would be delivered, set up, tested, and payment made on the spot by certified cheque, upon my satisfaction that they were as advertised. The kicker was that I was willing to throw in an extra $70 for the delivery service -- that's what the shipping charges would have run, so it seamed fair.
To date, I have not been scammed on Ebay. I suppose it will happen at some point over a relatively small purchase. But, one has to weigh the risks against the convenience and rewards of an online auction system.
You may get far less customers, but you probably get far more knowledgable ones. I wonder how your support costs compare to a telco that caters to the sheeple that flock over to "that thar internat thingy". Covet not the attention of morons for, while many in number and flush with coin, they will vex thine support staff.
Where the smaller ISP can shine is in providing superior and distinct services. For example, I sink my own email -- it's the primary reason I have a static IP address. Still, I like to have a backup MX somewhere that can cache mail when my inbound server is down for maintenance. Right now, the comnpany hosting my website provides this, but remote access is via POP. I fetchmail from them and let my local sendmail sort things out. IMAP-SSL would be better, but they don't provide it. Still, if you're at the end of a fixed DSL link and my traffic routes through your and the telco's switches, I could tolerate plain-text authentication to your servers. Remember when plain text PPP authentication over dial up was just fine? Same principle.
So, sell me backup MX services, DNS for my domain, maybe a caching NNTP service, and while you're at it, NTP would be real great. Heck, throw it all together and sell me a real "domain" package deal without raking me over the coals: despite having a personal "family" domain, I don't run a biz, don't have large amounts of outbound traffic, and don't need a domain cert for commerce. I don't want to pay per-email address: just cap my aggregate inbound (backup MX) mail spool. Oh, hey, sell me a local VoIP PSTN "hop on" number, and partner with one of the bigger VoIP carriers, reselling their service. Retail some SIP hardware, like APs, SIP phones, etc.
I think there's lots of services a smaller ISP can offer to make themselves attractive to a larger audience that do not involve large amounts of outbound traffic.
I gave Verizon every chance to sell me the service I wanted: 1.5Mx384k, one static IP address, no unreasonable monthly caps (yeah, so I downloaded Fedora Core 2 sources and binaries, so?), and the freedom to open any port I like that requires authentication (SSH, IMAP-SSL), and commonly used ports (like SMTP) to anyone. I'm willing to accept reasonable restrictions on the ports providing anonymous access -- i.e. "thou shalt not relay email!". So, Verizon, sell me.
Well, first they said that a static IP was only available for "business" service. O.K., how much? Well, it was about $10 a month more than I really wanted to spend ($90 as opposed to $80), but I could squeeze somewhere else - $10 is worth the hassle to not deal with separate DSL and ISP providers. You'd think it would be a slam dunk sale for their 'droid, right? Wrong. They won't sell "business DSL" (and this doesn't even include QoS commitments) to residential addresses. I tried. Fuck you, Verizon. Hello, Blarg!
The fact that people like me are willing to pay double for marginally upgraded services should send a message to telcos like Verizon. If they could provide the service I want at a price I'm willing to pay, I'd buy it from them. Still, they have no right to complain: I'm still paying them more for the pipe than I would for the pipe and service from them (albeit, somewhat crippled service).
It's questionable whether a free market could provide this level of service (essentially unmettered 1.5Mx384k DSL with a single static IP) for less. That I can get a degraded level of service for less isn't the question: I can -- I just don't want it.
Just about all non-Verizon ISPs charge around the $30 a month rate over and above the line charge for a static IP. Of course, if you go with the resold Verizon dynamic IP package, the whole thing can be bundled for around $25 or so. Verizon charges around $100 a month for it's "business class" service with a static IP and, interestingly, won't sell it to residential addresses (this is poor-man's biz. DSL, BTW, without any QoS or uptime guarantees). At leazst
Verizon competes with Comcast in the "crippled broadband" arena, so their crippled service pricing is somewhat capped by that limited competition. More exotic alternatives like satellite, and fixed wireless, are more expensive than $25 a month and generally require greater capital outlay. So, it stands to reason that $25 a month is a reasonable "rock bottom" estimate for the price of crippled service to be sold at a profit.
Against that, paying double for decent, uncapped, unfiltered service, with a static IP address is not unreasonable.
Would I like to pay less? Of course. Do I think I'm being gouged? No.
This is misleading. I have Verizon service (POTS and DSL) in Monroe, WA, and they don't touch my traffic and don't give a fig about what servers I run.
See I have DSL service from Verizon, but they are not my ISP, so I don't have to put up with assanine ToS. I get my internet connectivity from blarg.net. Verizon just provides the backhaul from the DSLAM to Blarg! And, to their credit, Blarg! doesn't use MTU-mangling PPPoE. Just one long virtual circuit private "electonic highway" onramp for me (well, a dedicated lane on that onramp, if you really want to push the analogy -- work with me here :-)). My "always on" connection is very much always on.
Verizon sucks rotten eggs, as far as serivce is concerned (took 'em forever to acknowledge that, yes, I had an international long distance plan, and no, my calls to Canuckistan were not to be billed at $0.75/minute), but I'm stuck with them as a telco. So, I subscribe to what little I can. In this case, that means just the data pipe from me to my ISP.
There is a bit of a downside, of course, and that is price. But, it is not unreasonable: instead of some $30 a month for neutered dynamic IP access, I pay them closer to $40 a month just for the pipe and another $35 a month or so to Blarg!. Static IP? No problem (well, it costs a bit extra, included in the above price). NATed hosts? No problem. Inbound SMTP? No problem (but don't relay please: the IP address is ours and we like to keep a clean anti-SPAM reputation). Inbound telnet? Hey, it's your security, do what you want. Sure. Inbound HTTP? It's your box you're Slashdotting, not ours.
Now, of course, there are a few things I shouldn't do that'd hurt Blarg!, like run a busy site at the end of a DSL link, but those kinds of things would be bad to me too. Still, no one is going to cut me off for opening up port 80 for a day or two of private testing.
So, yeah, sure, sell me a fatter cheaper pipe Verizon. If all you can do with a modest degree of competence is sell pipes, do that.
Obviously, not to the desired effect.