I save enough in LD charges with mu VoIP service to justify the cost of the service AND keep POTS for local, toll-free, and emergency calls, if necessary.
Encouraging the breaking or even bendiung of the law in order to stay employed is horrid. In my case, even the slightest infraction can get me deported as I am in the U.S. on a work-related visa -- this includes a traffic ticket, in theory.
If you want to boost my morale, get me better equipment. Get everyone better equipment. Don't waste company money on five star hotels, and sleazy entertainment. Provide a better health insurance plan for employees if you want to spend the money.
I'll take the class, pay for my own meals and local transportation, and spend my down time studying the material and resting for the next day, thanks. I would view the type of activity you describe as an attempt at punishment and would start to seek other employment. I don't care for night clubs. I might enjoy a pint or two of Guinness in a decent pub, but that's about it.
Send everyone else: when others don't code, I don't have to fix their bugs.
You must have offended some mod point wielding socializer with the F word, there.
Yeah, well... I've got karma to burn -- you should read some of my anti-Canadian communist rants (I had the misfortune to be born there, so I figure I can criticize it with impunity).
The +5 mods cancel out the -1's pretty well.
I usually don't curse like that, but forced "morale" events really tick me off.
Perhaps some of us prefer to use what little time is our own for ourselves.
You want me to go to a non-business event outside of regular hours? Pay my expenses and hire me at my contracted per-hour rate. I'll sit in that bar for ya, then.
Otherwise... FUCK THE HELL OFF!
Seriously, nothing pisses me off more than an organized "morale boosting" event. I get a strong urge to treat the organizer to the business end of an AR15. While I don't act on that urge, of course, I can well imagine a less stable individual going all out, with gusto. Perhaps then the trend among idiot PHBs will be to stop suggesting such lunacy, even if only out of fear of personal harm.
Who goes to such events? The people who work the hardest, find and fix the bugs, and generally try to deliver decent code? No, the people who made the mistakes in the first place and don't care about the quality of what they produce.
Indeed. In Ontario, Canada, you can be sued for damages (with a good chance of success) if you leave an employer "precipitiously".
Of course, once on the job for 90 days, it's much harder for you to be dismissed without cause. This is so pervasive that you can't get approved for a mortgage within the first 90 days of starting a new job: kind of makes relocation a drag.
Re:Removing motivation to create innovative IP
on
Is IP Property?
·
· Score: 1
Their defense needs and military commitments are very different from those of the United States.
I don't know if I agree with that. If it is true, then perhaps the U.S. has "grown too big for it's britches" and pissed too many of the wrong kind of people off with it's foreign policy.
I used the example of Switzerland during WWII precisely because it demonstrates that an armed but relatively untrained militia, can deter invasion by a much more powerful force.
Of course, the approach of strict neutrality hasn't hurt them, and that's an area where the U.S. is in a vastly different situation. Chickens... home... roost.
Still, do not discount the disruptive effect a hostile, widely dispursed, guerilla force can have: it's the one opponent that the U.S. has historically been bad at defeating. Iraq is a pretty good example of that. Vietnam is another.
By the way, what did you think about the idea of computers and the internet turning information into a public good?
I think the value of information will ultimately relate to it's timeliness: news has more value than a table of physical properties. Interestingly, this will render the problem of "unauthorized" redistribution rather moot.
We see this now in stock quotes: real time quotes require subscription to a service, but delayed quotes, even 15 minutes stale, are free.
Re:Removing motivation to create innovative IP
on
Is IP Property?
·
· Score: 1
But once every third person on the block sees that their neighbors are getting national defense for free, they decide not to renew their subscription.
So?
Either accept the free riders, and "punish" them via shunning (which can be surprisingly effective), or go without,... or find an alternative. You seam to argue that there is no alternative.
If I am wrong about national defense, then why is it provided by the government, and not by the market?
In Switzerland, it's provided by a cooperative of all able-bodied men in the country: each is required to have and maintain a semi-auto weapon, and to be skilled in it's use.
While membership in this "co-op" is mandated by the state, there is no national oreganization that provides self defence run by the government.
IIRC, Switzerland was one nation that Hitler's Nazis could not invade. They certainly had incentive as it became a haven for people with wealth (as well as, ironically, ill-gotten Nazi booty). So the argument that a militia can not defend against a modern army, and the "power" of the state is necessary to do so, is flawed.
Re:Removing motivation to create innovative IP
on
Is IP Property?
·
· Score: 1
If I write a book now, I instantly get all the protections of the state with regards to copyright (whether I like it or not).
A registration based system would mean I have the option to let my works go into public domain or I must pay a periodic fee so that I get the protections of the state.
You appear to be confusing a law that provides for civil enforcement at law with criminal enforcement at law. Current IP law provides for both: you can chose to sue for copyright infringement, or not. The incremental cost of such a suit to the state is negligible (overhead of providing a court and judge), so funding it isn't an issue even if you never chose to pursue such a suit. You have little choice when it comes to criminal prosecution. That's expensive for the state, and you pay for that "protection" whether you want to be "protected" or not. You should not pay for it if you don't want the protection. (I would guess, however, that a criminal copyright prosecution would not go very far without the cooperation of the copyright holder, even though the state did not require it. I can imagine, however, that it might be used to stop distribution of "sensitive" works that the author has agreed to not distribute, but which have "escaped").
You always have the option to release works into the public domain. Though, if you do this exclusively, you should not fund the protection of copyrights via criminal prosecution.
This system already exists, its the RIAA and MPAA. They are subscription services that represent the best interest of their members. This system is okay, except that it only provides protections to the members not to the public.
By itself, this is not a problem. What is a problem is that these organizations are bullies that try to purchase laws to their exclusive benefit.
Re:Removing motivation to create innovative IP
on
Is IP Property?
·
· Score: 1
The designation of public goods is important because the market is not very good at supplying them, due to the free rider problem. The classic example is national defense. There's no good way for someone to sell national defense to only paying customers. If I were to try to start a company that sold national defense to people, and my services were bought by every third person in America, how would I prevent the non-customers from enjoying the benefits of my service?
I disagree.
If only every third person paid for a national defence service, they would still get the level of service for which they paid.
The free rider problem is not a problem for goods that are non-depletable. It is only a problem for those that would seek to maximize profits and those that don't like to see others get a free ride even if it means that they do not get any less value as a result.
The way to "deal" with free riders is to shun them from the trade relationships between non-free riders, or discriminate economically against them: "Your son didn't fight in the war that saved our homes. Mine did and died. I will charge you double for gasoline you buy from me."
Re:Removing motivation to create innovative IP
on
Is IP Property?
·
· Score: 1
I agree, there should be some taxation on intellectual property (ie copyright registration), similar to car registration and property taxes, to pay for enforcement.
That's not what I wrote: I never proposed a "tax".
A tax would be levied on all producers of intellectual property that was shared, whether or not the producers would desire the benefits of enforcement. That would be wrong. Would you want to see Linux ior FreeBSDtaxed heavily? (Well, I can think of some organizations that might like this idea!).
The enforcement of intellectual property laws should be paid by subscribing to a service, and not by a tax. In my example above, perhaps providers of Linux distros might subscribe voluntarily to such a service in order to have the financial means to act against GPL (or, in the case of FreeBSD, BSD) violators.
However, I should not have to pay it if I provide a Fedora Core CD set to a friend, even if he pays me for it.
Should we expect "the average person" to be "net-savvy"?
I of course, think so... duuuh! But, I am probably in the minority when it comes to that opinion.
Re:Philosophical v. practical origins of IP law
on
Is IP Property?
·
· Score: 1
Just because there are IP rights defined in law it does not immediately follow that you cannot dispose of those rights in any way that you like; including and not limited to for example, releasing your rights under a GPL licence in the case of software.
Ironically, I once debated with RMS about the right to give up rights: he argued that this was dangerous because duress would be used to get people to "voluntarily" surrender rights they had.
IP property rights equally and reasonably applied to all is the best way to form a free and creative society.
Yes, but any organization strong enough to enforce rights on behalf of the weak is certainly strong enough to deprive them of those rights while propagandizing that it is, in fact, enforcing them on behalf of their "rightful" holder.
Re:Removing motivation to create innovative IP
on
Is IP Property?
·
· Score: 1
I'd mod you "Funny", but alas, I wrote the original article.
Re:Removing motivation to create innovative IP
on
Is IP Property?
·
· Score: 4, Insightful
What a lot of people who take this kind of position often don't realize is the fact that treating IP as property, and protecting peoples' rights to those properties, is what provides the motivation for many of people to be so creative and to pour themselves into their work.
So, the decendents of Og, inventor of the wheel, should receive royalties from everyone who rides, drives, pushes, or pulls devices with "circular freely rotating attachments designed to facilitate movement"? In perpetuity?
Somehow, that strikes me as absurd.
Yes, developing ideas takes effort, and that effort is more likely to be expended if the ideas can be leveraged to produce income, and correspondingly, the source of that income stream protected. Thus, the notion of ideas as property, with the notion of owners, is born.
But, how does one protect one's property? Did Og kill others who also made wheels? Or, did he just smash their "copies"? Perhaps he traded some fur skins, or free wheels he made to bigger, meaner cave-persons to do that for him. In any case, protecting property takes effort and has a cost associated with it.
The trouble with existing laws that provide for the protection of property is the cost of enforcement is borne by all members of society via the taxes they pay and is not directly related to the value of the property so protected. Yes, income taxes are progressive, and physical property taxes are proportional to the value of the physical property, but how does one (a) value ideas, and (b) account for the ease with which they can be used by others (and conversely, the difficult to prevent such use)?
One can keep an idea secret. Perhaps the idea behind the physical manifestation of its application is not obvious (i.e. "my" wheels have roller-bearings between the bodyu and axle that you can't see). But, increasingly, ideas have the greatest value when they can be applied far and wide, to the benefit of the most people, and, in retrospect, are either "obvious", or easily reapplied (software is a perfect example of the latter, being in between an algorithm and an execution thereof). Keeping them secret reduces their potential value.
In a free world, ideas would be secret unless licensed, subject to agreed-upon terms (including, obviously keeping the secret) at a cost that, amount other things, pays for enforcement of the contract, if necessary. This, however, does not scale well. Furthermore, the damage that can be done by one individual breaking the secret can far exceed whatever one could recover from them. While the notion of ideas subject to conditions regarding their use is not a problem, morally enforcing those conditions against those who have not agreed to them is. We need a notion that is so widely accepted, that there is no question that enforcement can be morally applied. "Property" is one such notion. We respect the property of others even though we may not have contracted explicitly to do so. We do this either because we think it is right, or because enough others do that they fund the enforcement of the notion. While a contractarian may have a problem with this "implied agreement", it is easy to show that acceptance can be tied to permission granted to use non-private shared resources: i.e. if you steal, you can't move around in the places you don't own (public roads), and because you broke that deal (having previously used the road to come and rob someone), we'll lock you up. Not only is that effective, someone in jail can't continue their theft spree. (Of course, incarceration carries it's own costs).
So, the notion if "intellectual property" is an easy one to grasp and accept -- no widespread riots opposing it (though, the widespread use of P2P techniques to share copyright music is an interesting form of civil disobedience). We can pay the state to enforce copyrights, patents, and trademarks, at least as far as criminal infringement goes.
The problem however, is, again, that the cost of this enforcement, is not borne in proprotion to the in
I'm not talking about any of the email headers. I'm talking about the actual IP address of the email filter that contacted my SMTP server with the bogus bounce: it, unfortunately, trusted the From: address.
Now, this could come from a zombie, or an SMTP proxy, but in either case, there exists a party that can be held responsible
Great, now, let's see if you can actually GET a Million Packets in a Second just to the hardware, let alone to the software. Hmm.
When I worked at Chiaro, we routinely handled saturated optical GbE links as part of testing. Of course, these didn't handle bulk data traffic, just the routing protocol updates:-> for the control processor(s) for the real router, which was all optical. I forget how many hundred OC-192 (10 Gb/s) ports it could handle.
My job there involved, among writing and backporting GbE drivers for Intel NICs under FreeBSD, stress testing their STAR mechanism: this was designed to ensure if one router control processor went down, there would be no loss of functionality -- the secondary router control processor was on hot standby and knew all about the routing table state of the first one.
While running Win98 naked is about as wise as, well, running naked, this may not be the source of those bounce messages. IOW, by themselves they do not indicate that your box is a spam zombie.
I get boatloads of these things, as well as spam (filtering is your friend) -- my email address is fairly public and in a lot of address books. I'm not about to abandon it as it's within a domain I lease.
I run behind a fairly hardened firewall, and am moving towared a Linux iptables-based firewall/router/home server.
What ticks me off is when such a message bounce indicates that the original message contained a virus. How dare someone accuse me of sending a virus just because their mail daemon received a spoofed From: header? They could at least check the route the mail took against that header to get an idea if it's bogus. But, often automatic smam/virus filters are pretty stupid and trust the From: address. Still, I wonder if someone, somewhere, "out there" is blacklisting me because someone else forged my identity. Sounds like a defamation suit if I could find the bastards.
And that's the rub. Often when I've received such bounces, when the originator can be identified, they refuse to help in providing a copy of the original email, headers intact, that might permit tracking down the source: either a spammer, or a spam-zombie. I wonder if I could sucessfully file "theft of computer services" charges against such an organization: they're sending me unsolicited bounces, and furthermore, refusing to backup the allegation that they're bouncing messages from me. I wonder if the anti-spam legislation that's out there can be used as a club against those who send bounces to spoofed From: addresses and refuse to acknowledge or correct their mistake.
But if you're contantly reformatting, you're constantly going to be taking a performance hit over the entire length of a project. It's just not worth it.
Not if you have your tools properly set up: any shop that has a mandated repository source code format should provide tools to convert to that format. The tool can count spaces and apply rules better than you can, and won't make a mistake (of course, it won't bend the rules when appropriate either). Editor support is one aspect of the supporting tool set -- you wouldn't suggest a formatting standard not supported by most editors, would you? (Agh! I can see editor wars heating up for lack of support for a given formatting standard -- now that would be ass-backwards).
Well that's just completely insane. Did they also forbit the use of compilers and have you enter machine-code directly? I assume you got the hell out of there.
I got out of there, yes, but it took a while. We were explicitly forbidden from developing any tools, on our own time, at home, that might make our lives easier either: the reasoning was that if we were willing to work, we'd be told what to work on.
But such shops are, sadly, not that rare, and a call for a common formatting standard, without caveats or reservations, results in absurd requirements when used in such a place, like, "We can't leverage or modify Apache for our needs or write a module for it. If Apache wants us to use it, they will defer to our coding style."
Yes, thanks for proving my point: You need to accomodate multiple styles. So you may as well get used to working in multiple styles.
Except, that was not your original point, which was to conform to a master style. That is, as I've said, a fool's errand, when one has to deal with legacy or imported code from other projects, internal, or external. It would have been folly, for example, for me to have enforced a coding style for all components of the custom RH-6.2 Linux distro I developed in-house.
If I have to adapt to alternate styles, I expect my coworkers to do so as well. In fact, I will be less inclined to conform to your style, if you do not extend the same curtesy to me. The justification for a common repository style does not come from mob rule, and, even then, it has limited applicability if your repository caches foreign code.
Yes, so your project is going to cost $n and take m hours to complete. So you got paid $n/m per hour. You are "doing hours".
No, I got paid $n, and would have gotten paid $n (for contracted work) even if the project took twice as long (or less, if I agreed to penalty clauses). I may have earned money at a rate of $n/m dollars per hour, but that's not the same thing: the rate was established by my productivity and not by contract. The same holds, although to a lesser degree, when salaried: too low a productivity and I'd be spending many extra hours working.
I'm sorry, but I simply don't belive you. Very few open source projects run any sort of tool checking for correct formatting upon commit.
Teradyne, c. 1998: source reformatting on checkin was du rigeur for text versions of Rational Rose UML exports. Of course, Clearcase made this easy to implement (as well as email notifications to "interested" parties on checkin, etc.) and it was extended to other checkins. Clearcase was, of course, an expensive ($1000/floating seat/year) pig of a source code control application, but it had some nice features, nevertheless.
My original point was that you are paid to do the work, so you're going to do it how they want, or not get paid.
Not for very long, I won't, if the process adds inefficiency or is designed to compensate for inadequacies of poor staff. Such companies do not do well, in the long run and I have no desire to be part of their downfall.
"What I usually find is that often I have to go back and correct someone else's work."
I'm looking, but so far I haven't seen any such evidence in your argument. Maybe I am a bit dense, can you summarise it for me?
I didn't think I had to cite every reference... I've noted ratios of productivities within a team. Google for the appropiate documentation to back that up. But, basically, a 10% hit on someone who's 10 times more productive than average hurts a lot more than a 10% hit on someone who's average.
*This* is where tool support is useful. Set up Emacs/vim/whatever so that it implements in-house style rules. When you commit, checkstyle (or similar) runs and prompts you to fix formatting errors before the changes are accepted in the repo.
That would be good, yes... if the shop permitted this. However, the shops I've experienced with the most draconian formatting and layout rules also forbid the use of automated tools to support them! The shops with a more relaxed atmosphere, and a "recommended" style, generally encourage their use.
I remember a shop which required 120 pages of internal documentation for some 6000 lines of new code produced within 2 weeks. Well, doxygen is your friend here, and helped get the work done on time, with the support of all teammates, particularly those who used it before. Management, however, decided that using such a tool was "unproved" and "risky" and the work was to be redone manually, with now slip in schedule and a day left! This, after the fact, with excellent results (printed, and hyperlinked online docs). Needless to say, I buggered out of there pretty damn quick, to the dismay of those who would have liked me on their team (which was not permitted without the approval of one's current manager -- a real biggoted arsehole if I ever met one). Getting paid a nice bundle more, too.
These same kind of morons who will take a common coding style position and not consider the overhead of conforming to it. In extreme situations, the benefits often do not outweigh the costs. I'm called upon the "save the day" in just those kind of extreme conditions, when someone has, for example (this is a real world example), delivered 8000 lines of multithreaded Java code but was oblivious to the use of the "sychrinized" keyword, and that, gues what, doesn't work, with three days before an integration deadline. The last thing I will worry about is ensuring I adhere to a formatting style -- It's my job to make it work, on time -- never mind that I haven't seriously used Java before.
Is that how development should be done? No, of course not. In a "perfect" world, we'd have the luxury to take the time to adapt to what ever conventions exist. Unfortunately, development is far from perfect, and the best are usually called upon to clean up the dirtiest mess.
Your point appears to be that a common style improves communication and therefore productivity. That it does, but it is not the only thing that does so, and carries a burden of it's own. Better developers also adapt to differeing styles when necessary to read them. It's the writing that's a pain when you're in a crunch. When 90% of the work is making sure the i's are dotted and the t's are crossed, something is wrong. And this overhead increases with productivity.
Before I continue here, from the arguments you make, it has become clear you have worked on few projects where you had to interact with other people. In essense, it sounds like you would normally start working on a project and stop only when you feel like you have done enough for the day/night/whatever. It sounds like you work in an room, by yourself, without any communication with anyone else except at the start and end of the project.
It doesn't sound like you have been part of a team working on a product, or part of a team working on a component that gets used by other developers.
Lesse, ADAS+: 100+ developers in three locations; RMU75x: 8-16 developers delivering a test head to BT to teast "each pohone line, every night".
and trademark or copyright ancillary components bundled as part of the aggregate. You can aggregate non-free and free stuff, you know.
That way, when someone gets a Red Hat distro, they know it's "official", if the law has been followed.
Yes, yes, that's a big "if". But it's a start: you can have the GPL and still restrict what others can pass off as an "official" version.
The next step, of course, is to have a trusted source sign the aggregate and important components thereof. That has the advantage that redistribution of the aggregate in toto does not have to be curtailed to make sure that each copy is legit.
I am not talking to other staff when, er, I'm not talking to other staff.
It should be obvious that one trivially reformats to a publication standard to discuss it.
The whole jist of your argument appears to be "don't work this way because it will reduce your productivity, and see, when you work that way, you are more productive than average." Experience has taught me that, no, it doesn't reduce my productivity just because it might reduce someone else'sm and if you left me alone, I'd be five times more productive still.
Disbilief of my assertions might be one thing, and understandable, but to ignore the proof when the pudding has been presented, is moronic.
I am not arguing that it is impossible to deal with a foreign formatting standard. I am arguing however that this (a) slows down implementation (counting spaces and looking up style rules just to open a new basic block), and (b) enough to have a noticible effect on productivity.
Perhaps you do not find typing speed an implementation bottleneck, but those of us who regularly crank out 20k lines of production quality code a month, do. For an 8 hour day, that's around 30 seconds per line of code. Stopping to worry about style is going to kill that by a noticible margin. At some point, one leaves the design phase and has to implement. The "how" answered, the "picture of the code" clear in one's mind, the last distraction one needs is "does this break style?"
And yes, I have the world class profitable shipping products under my belt to back those quality, and bravado assertions. You've probably used them if you make telephone calls.
Take some time to research productivity and quality metrics across professional developers some time: you'll find a one (some would argue as much as two) order of magnitude difference between best and average. Of course, if you've never been "in the zone", you would not believe this possible.
Right, so your contract doesn't specify how many hours you are expected to show up and do work?
No. It specifies what is to be done, and when it is to be delivered. If that means 10, 20, 40, 80, or 120 hours a week of work, so be it.
When salaried, the only metric is "ship what works on time", with the implied requirement "even if this means taking the time to fix other people's fuckups". Teamwork is not "everyone goes to the company-sponsored social event". It's "You drop the ball, I catch it."
In fact as a salaryman, if you are in the tech industry you're probably going to be required to work overtime without remuneration.
You don't get it, do you?
For a hard-core hacker, it isn't about overtime, or salary. Money is nice, of course, but I do what I'd do because I'd do it anyway. So, the concept of "overtime without remuneration" is meaningless -- the pleasure comes from the work. The compensation is a nice side effect that takes care of essential needs.
Is that an attitude ripe for employer abuse? Of course it is. However, abusive employers and managers soon find that there are plenty of employers out there who are not abusive, and when the time is right, it's "Adios!" The funny thing is that better working conditions have tended to go hand in hand with (substantially) more money. I've never encountered an enjoyable job that, otherwise, paid badly.
One can argue that "work is not life", but if you spend 30-50% of your time doing something, it better be something that you enjoy doing, and that, ultimately, work is, indeed, a major part of life.
I find more recent Red Hat distros (RH 8.0, FC1 and FC2) to be harder to install, configure, and use, than older ones (like RH 5.x through to 7.2).
I started with a Slackware predecessor (you know, the "A" series, "B" series,... "X" series (that was a big one)) and am quite comfortable customizing/etc/... configuration files manually, at least the obvious ones. Sendmail is still a bit of "black magic for me", solely because I just "set it and forget it" and have not bothered to really study its arcane config files. Still, Google is your friend here. So, I'm not exatly a noob.
The trend from 5.x through 7.2 was one of improved installation, better device support, etc. More systems would work out of the box. Still, one had to look elsewere for support for modern printers, V4L was a dependency hell issue, and, eventually, the build tools were too out of date to even build all the fun stuff from source any more. Time to move on. I looked at FC1 and FC2. That's when the grief started!
Installing either was a no brainer, and automatic X configuration has gotten fairly good, but lo, FC2 would not get me into a graphical login despite setting the initial run state to 5. The frustrating thing was that startx appeared to work fine. It turned out to be a dependency issue on a DRI (I think) kernel module that was not loaded. Time to configure and build a custom kernel (and modules) for the box.
Now, I may have just been unlucky, but I didn't think an AIW video card was that obscure as to have this kind of problem. Anyway, I build a kernel, make an lilo.conf entry for it (still to lazy to pick up grub configuration -- it's on the list), reboot, and... yay! it's comming up..., no, wait, why is it hung probing for new hardware? Grrr.
Turns out I was a little too liberal in configuring the optional hardware in my kernel config. So, I take the opposite approach, enabling things I know I have or are known to be "safe". Well, this works better! Ah, even X comes up in run level 5.
Phew, that was a lot of unexpected work.
After running for a while, I notice that eventually the system hangs when I try to log in. It turns out that the nifty bits that change device ownership on graphical login (FWIW, I use Gnome) on the console sometimes don't change it back, or think that the last user hasn't released the console. This, in turn, causes something to wait forever trying to get the sound device.
Now, in fairness, I had a similar problem with RH 7.2 that I hadn't resolved, in that sound device ownership sometimes didn't get set to the current console user, but that didn't hold login up. There was nothing obvious to indicate what the problem was at first, either -- no "Sound device unavailabe, ignore?" popup, or other indication. Took a bit of digging to find it.
Perhaps I log out "wrong". I've used ctrl-alt-backspace for years. Did that become a bit too drastic at some point? Google or RH Bugzilla weren't too helpful here -- describing such login hangs, but generally not related to my specific symptoms.
In fairness, the "fancy" USB Epson CX6400 printer/scanner/copier was supported with minor configuration by both the printing system and SANE -- I'd had grief with a Canon BJC 2100 in the past for which Canon provided no helpful support, and reverse-engineered drivers were poor and didn't support the scanning mode at all. So, despite the encouraging research that it was well supported by the printing system and SANE, it was my first USB peripheral, and a bit of a leap of faith. (Hey, Fry's had it on sale). Of course, mature USB, printing, and scanning support were one of the reasons I moved to FC2 in the first place.
But, the login issue makes it fairly unusable for now -- the wife and kids still use RH 7.2. I suppose I could bypass the automatic device ownership on console login change and make them generously shared -- it's not like there will be contention for them, but it bugs me that an existin
South American coffee, in general, is lousy, though Columbian is probably the worst. Most (if not all) of it is Robusta, which, while higher in caffiene content than Arrabica beans, lacks in the tastefullness department. The thing to do is to increase the caffiene content of Arrabica beans, not Robusta beans.
Of course, if an Arrabica espresso isn't enough of a jolt for you, just make it a doppio (a double).
Personally, I prefer African coffees, and have a fondness for Kenya AA beans as far as run of the mill coffee goes, though many find them too strong (tastewise).
The problem being you need to reformat from your personal choice to whatever is the standard whenever you aren't just editing the code locally - when compiling, committing, diffing, whatever, so that all other interactions with your code match the standard. The first case makes your life difficult because line numbers on debugging symbols stop matching what is in your codebase and what others see, as does the latter because your diffs won't match your code.
Now, who's smoking crack?
When developing, you reformat to your preference, and all debug information matches what you've got -- about the only time this breaks is if you've got external references to precompiled components with a different layout. But, even then, if that code requires your attention during a debug cycle, it's not hard to reformat and recompile. (This does presume that all source is available to you, and a preponderance to "build everything (that matters)" in a build cycle. That is less than ideal, of course, but typical as most shops don't bother with proper dependency checking to be confident enough to not have to build everything all the time).
There is a tradeoff in managaing code in multiple presentations, and, indeed, sometimes it is not "worth it". However, when adding large blocks of new code, the freedom to lay it out as one likes buys a lot of time.
When you're ready to checkin, you again reformat to the standard, and generate diffs as appropriate (if necessary). To share context diffs requires only two things: an original version in a known format, and a diff that applies to that format. With originals in standard and personal formats, and a modified version in one of the two formats, generating diffs to either original is trivial.
I suppose that one could make the argument that all that reformatting takes too long, and without an understanding of the toolchain, this might be true. But to presume that just because something is time consuming for one, or even many, means that it is time consuming for all is folly. Processes which improve productivity by 20% for 8/10 developers on a team are useless when they kill productivity by 90% for the other 2/10 developers who are already an order of magnitude more productive than the rest (and this is typical in a shop). Before: Productivity = 8 * 1 + 2 * 10 = 28. After: Productivity = 8 * 1 * 1.2 + 2 * 10 * (1-0.9) = 9.6 + 2.0 = 11.6. Ideally, you want to be in a situation where you get the 20% boost for the mob, but only take a 5% cut for the rest: 8 * 1 * 1.2 + 2 * 10 * (1-.05) = 9.6 + 19 = 28.6. But, even here, the slightest impediment to your "best" hurts a lot.
Gee, and the selfish mob expect you to do work for the hours they pay you for. How naive.
Incorrect.
A common empoloyer may. Furthermore I don't "work hours". I am either salaried or work on contract.
The problem does not stem from reasonable alternate formatting styles. The problem stems from a need to very rapidly contribute hundreds or thousands of lines of code to a project without getting bogged down in the details of a particular formatting style, or worse, a style that prevents some syntactically valid programs from being written.
Perhaps I have been lucky, but I have never had to suffer idiot managers or coworkers for very long. However I have met some real idiots in my day (like people who don't realize that sizeofadds to portability and does not detract from it).
In any case, I like to have an "out" that permits me to escape standards lunacy where necessary -- shops that insist on a presentation style yet refuse any type of automated tool to help achieve that style for example.
Draconian dictation of program formatting style is a sign of inflexibility that interferes with getting a job done and tends to go hand in hand with an inability for developers to handle abstract designs and OOD and OOP in general -- the common focus being an incapacity to generalize what "reasonable formatting" is, and so requ
Slashdot Mirror
I save enough in LD charges with mu VoIP service to justify the cost of the service AND keep POTS for local, toll-free, and emergency calls, if necessary.
Encouraging the breaking or even bendiung of the law in order to stay employed is horrid. In my case, even the slightest infraction can get me deported as I am in the U.S. on a work-related visa -- this includes a traffic ticket, in theory.
If you want to boost my morale, get me better equipment. Get everyone better equipment. Don't waste company money on five star hotels, and sleazy entertainment. Provide a better health insurance plan for employees if you want to spend the money.
I'll take the class, pay for my own meals and local transportation, and spend my down time studying the material and resting for the next day, thanks. I would view the type of activity you describe as an attempt at punishment and would start to seek other employment. I don't care for night clubs. I might enjoy a pint or two of Guinness in a decent pub, but that's about it.
Send everyone else: when others don't code, I don't have to fix their bugs.
Yeah, well... I've got karma to burn -- you should read some of my anti-Canadian communist rants (I had the misfortune to be born there, so I figure I can criticize it with impunity).
The +5 mods cancel out the -1's pretty well.
I usually don't curse like that, but forced "morale" events really tick me off.
You want me to go to a non-business event outside of regular hours? Pay my expenses and hire me at my contracted per-hour rate. I'll sit in that bar for ya, then.
Otherwise... FUCK THE HELL OFF!
Seriously, nothing pisses me off more than an organized "morale boosting" event. I get a strong urge to treat the organizer to the business end of an AR15. While I don't act on that urge, of course, I can well imagine a less stable individual going all out, with gusto. Perhaps then the trend among idiot PHBs will be to stop suggesting such lunacy, even if only out of fear of personal harm.
Who goes to such events? The people who work the hardest, find and fix the bugs, and generally try to deliver decent code? No, the people who made the mistakes in the first place and don't care about the quality of what they produce.
Of course, once on the job for 90 days, it's much harder for you to be dismissed without cause. This is so pervasive that you can't get approved for a mortgage within the first 90 days of starting a new job: kind of makes relocation a drag.
I don't know if I agree with that. If it is true, then perhaps the U.S. has "grown too big for it's britches" and pissed too many of the wrong kind of people off with it's foreign policy.
I used the example of Switzerland during WWII precisely because it demonstrates that an armed but relatively untrained militia, can deter invasion by a much more powerful force.
Of course, the approach of strict neutrality hasn't hurt them, and that's an area where the U.S. is in a vastly different situation. Chickens... home... roost.
Still, do not discount the disruptive effect a hostile, widely dispursed, guerilla force can have: it's the one opponent that the U.S. has historically been bad at defeating. Iraq is a pretty good example of that. Vietnam is another.
By the way, what did you think about the idea of computers and the internet turning information into a public good?
I think the value of information will ultimately relate to it's timeliness: news has more value than a table of physical properties. Interestingly, this will render the problem of "unauthorized" redistribution rather moot.
We see this now in stock quotes: real time quotes require subscription to a service, but delayed quotes, even 15 minutes stale, are free.
So?
Either accept the free riders, and "punish" them via shunning (which can be surprisingly effective), or go without,... or find an alternative. You seam to argue that there is no alternative.
If I am wrong about national defense, then why is it provided by the government, and not by the market?
In Switzerland, it's provided by a cooperative of all able-bodied men in the country: each is required to have and maintain a semi-auto weapon, and to be skilled in it's use.
While membership in this "co-op" is mandated by the state, there is no national oreganization that provides self defence run by the government.
IIRC, Switzerland was one nation that Hitler's Nazis could not invade. They certainly had incentive as it became a haven for people with wealth (as well as, ironically, ill-gotten Nazi booty). So the argument that a militia can not defend against a modern army, and the "power" of the state is necessary to do so, is flawed.
Try making the mortgage payments on strike pay.
You appear to be confusing a law that provides for civil enforcement at law with criminal enforcement at law. Current IP law provides for both: you can chose to sue for copyright infringement, or not. The incremental cost of such a suit to the state is negligible (overhead of providing a court and judge), so funding it isn't an issue even if you never chose to pursue such a suit. You have little choice when it comes to criminal prosecution. That's expensive for the state, and you pay for that "protection" whether you want to be "protected" or not. You should not pay for it if you don't want the protection. (I would guess, however, that a criminal copyright prosecution would not go very far without the cooperation of the copyright holder, even though the state did not require it. I can imagine, however, that it might be used to stop distribution of "sensitive" works that the author has agreed to not distribute, but which have "escaped").
You always have the option to release works into the public domain. Though, if you do this exclusively, you should not fund the protection of copyrights via criminal prosecution.
This system already exists, its the RIAA and MPAA. They are subscription services that represent the best interest of their members. This system is okay, except that it only provides protections to the members not to the public.
By itself, this is not a problem. What is a problem is that these organizations are bullies that try to purchase laws to their exclusive benefit.
I disagree.
If only every third person paid for a national defence service, they would still get the level of service for which they paid.
The free rider problem is not a problem for goods that are non-depletable. It is only a problem for those that would seek to maximize profits and those that don't like to see others get a free ride even if it means that they do not get any less value as a result.
The way to "deal" with free riders is to shun them from the trade relationships between non-free riders, or discriminate economically against them: "Your son didn't fight in the war that saved our homes. Mine did and died. I will charge you double for gasoline you buy from me."
That's not what I wrote: I never proposed a "tax".
A tax would be levied on all producers of intellectual property that was shared, whether or not the producers would desire the benefits of enforcement. That would be wrong. Would you want to see Linux ior FreeBSDtaxed heavily? (Well, I can think of some organizations that might like this idea!).
The enforcement of intellectual property laws should be paid by subscribing to a service, and not by a tax. In my example above, perhaps providers of Linux distros might subscribe voluntarily to such a service in order to have the financial means to act against GPL (or, in the case of FreeBSD, BSD) violators. However, I should not have to pay it if I provide a Fedora Core CD set to a friend, even if he pays me for it.
Should we expect "the average person" to be "net-savvy"?
I of course, think so... duuuh! But, I am probably in the minority when it comes to that opinion.
Ironically, I once debated with RMS about the right to give up rights: he argued that this was dangerous because duress would be used to get people to "voluntarily" surrender rights they had.
IP property rights equally and reasonably applied to all is the best way to form a free and creative society.
Yes, but any organization strong enough to enforce rights on behalf of the weak is certainly strong enough to deprive them of those rights while propagandizing that it is, in fact, enforcing them on behalf of their "rightful" holder.
I'd mod you "Funny", but alas, I wrote the original article.
So, the decendents of Og, inventor of the wheel, should receive royalties from everyone who rides, drives, pushes, or pulls devices with "circular freely rotating attachments designed to facilitate movement"? In perpetuity?
Somehow, that strikes me as absurd.
Yes, developing ideas takes effort, and that effort is more likely to be expended if the ideas can be leveraged to produce income, and correspondingly, the source of that income stream protected. Thus, the notion of ideas as property, with the notion of owners, is born.
But, how does one protect one's property? Did Og kill others who also made wheels? Or, did he just smash their "copies"? Perhaps he traded some fur skins, or free wheels he made to bigger, meaner cave-persons to do that for him. In any case, protecting property takes effort and has a cost associated with it.
The trouble with existing laws that provide for the protection of property is the cost of enforcement is borne by all members of society via the taxes they pay and is not directly related to the value of the property so protected. Yes, income taxes are progressive, and physical property taxes are proportional to the value of the physical property, but how does one (a) value ideas, and (b) account for the ease with which they can be used by others (and conversely, the difficult to prevent such use)?
One can keep an idea secret. Perhaps the idea behind the physical manifestation of its application is not obvious (i.e. "my" wheels have roller-bearings between the bodyu and axle that you can't see). But, increasingly, ideas have the greatest value when they can be applied far and wide, to the benefit of the most people, and, in retrospect, are either "obvious", or easily reapplied (software is a perfect example of the latter, being in between an algorithm and an execution thereof). Keeping them secret reduces their potential value.
In a free world, ideas would be secret unless licensed, subject to agreed-upon terms (including, obviously keeping the secret) at a cost that, amount other things, pays for enforcement of the contract, if necessary. This, however, does not scale well. Furthermore, the damage that can be done by one individual breaking the secret can far exceed whatever one could recover from them. While the notion of ideas subject to conditions regarding their use is not a problem, morally enforcing those conditions against those who have not agreed to them is. We need a notion that is so widely accepted, that there is no question that enforcement can be morally applied. "Property" is one such notion. We respect the property of others even though we may not have contracted explicitly to do so. We do this either because we think it is right, or because enough others do that they fund the enforcement of the notion. While a contractarian may have a problem with this "implied agreement", it is easy to show that acceptance can be tied to permission granted to use non-private shared resources: i.e. if you steal, you can't move around in the places you don't own (public roads), and because you broke that deal (having previously used the road to come and rob someone), we'll lock you up. Not only is that effective, someone in jail can't continue their theft spree. (Of course, incarceration carries it's own costs).
So, the notion if "intellectual property" is an easy one to grasp and accept -- no widespread riots opposing it (though, the widespread use of P2P techniques to share copyright music is an interesting form of civil disobedience). We can pay the state to enforce copyrights, patents, and trademarks, at least as far as criminal infringement goes.
The problem however, is, again, that the cost of this enforcement, is not borne in proprotion to the in
I'm not talking about any of the email headers. I'm talking about the actual IP address of the email filter that contacted my SMTP server with the bogus bounce: it, unfortunately, trusted the From: address.
Now, this could come from a zombie, or an SMTP proxy, but in either case, there exists a party that can be held responsible
When I worked at Chiaro, we routinely handled saturated optical GbE links as part of testing. Of course, these didn't handle bulk data traffic, just the routing protocol updates :-> for the control processor(s) for the real router, which was all optical. I forget how many hundred OC-192 (10 Gb/s) ports it could handle.
My job there involved, among writing and backporting GbE drivers for Intel NICs under FreeBSD, stress testing their STAR mechanism: this was designed to ensure if one router control processor went down, there would be no loss of functionality -- the secondary router control processor was on hot standby and knew all about the routing table state of the first one.
I get boatloads of these things, as well as spam (filtering is your friend) -- my email address is fairly public and in a lot of address books. I'm not about to abandon it as it's within a domain I lease.
I run behind a fairly hardened firewall, and am moving towared a Linux iptables-based firewall/router/home server.
What ticks me off is when such a message bounce indicates that the original message contained a virus. How dare someone accuse me of sending a virus just because their mail daemon received a spoofed From: header? They could at least check the route the mail took against that header to get an idea if it's bogus. But, often automatic smam/virus filters are pretty stupid and trust the From: address. Still, I wonder if someone, somewhere, "out there" is blacklisting me because someone else forged my identity. Sounds like a defamation suit if I could find the bastards.
And that's the rub. Often when I've received such bounces, when the originator can be identified, they refuse to help in providing a copy of the original email, headers intact, that might permit tracking down the source: either a spammer, or a spam-zombie. I wonder if I could sucessfully file "theft of computer services" charges against such an organization: they're sending me unsolicited bounces, and furthermore, refusing to backup the allegation that they're bouncing messages from me. I wonder if the anti-spam legislation that's out there can be used as a club against those who send bounces to spoofed From: addresses and refuse to acknowledge or correct their mistake.
Not if you have your tools properly set up: any shop that has a mandated repository source code format should provide tools to convert to that format. The tool can count spaces and apply rules better than you can, and won't make a mistake (of course, it won't bend the rules when appropriate either). Editor support is one aspect of the supporting tool set -- you wouldn't suggest a formatting standard not supported by most editors, would you? (Agh! I can see editor wars heating up for lack of support for a given formatting standard -- now that would be ass-backwards).
Well that's just completely insane. Did they also forbit the use of compilers and have you enter machine-code directly? I assume you got the hell out of there.
I got out of there, yes, but it took a while. We were explicitly forbidden from developing any tools, on our own time, at home, that might make our lives easier either: the reasoning was that if we were willing to work, we'd be told what to work on.
But such shops are, sadly, not that rare, and a call for a common formatting standard, without caveats or reservations, results in absurd requirements when used in such a place, like, "We can't leverage or modify Apache for our needs or write a module for it. If Apache wants us to use it, they will defer to our coding style."
Yes, thanks for proving my point: You need to accomodate multiple styles. So you may as well get used to working in multiple styles.
Except, that was not your original point, which was to conform to a master style. That is, as I've said, a fool's errand, when one has to deal with legacy or imported code from other projects, internal, or external. It would have been folly, for example, for me to have enforced a coding style for all components of the custom RH-6.2 Linux distro I developed in-house.
If I have to adapt to alternate styles, I expect my coworkers to do so as well. In fact, I will be less inclined to conform to your style, if you do not extend the same curtesy to me. The justification for a common repository style does not come from mob rule, and, even then, it has limited applicability if your repository caches foreign code.
Yes, so your project is going to cost $n and take m hours to complete. So you got paid $n/m per hour. You are "doing hours".
No, I got paid $n, and would have gotten paid $n (for contracted work) even if the project took twice as long (or less, if I agreed to penalty clauses). I may have earned money at a rate of $n/m dollars per hour, but that's not the same thing: the rate was established by my productivity and not by contract. The same holds, although to a lesser degree, when salaried: too low a productivity and I'd be spending many extra hours working.
I'm sorry, but I simply don't belive you. Very few open source projects run any sort of tool checking for correct formatting upon commit.
Teradyne, c. 1998: source reformatting on checkin was du rigeur for text versions of Rational Rose UML exports. Of course, Clearcase made this easy to implement (as well as email notifications to "interested" parties on checkin, etc.) and it was extended to other checkins. Clearcase was, of course, an expensive ($1000/floating seat/year) pig of a source code control application, but it had some nice features, nevertheless.
My original point was that you are paid to do the work, so you're going to do it how they want, or not get paid.
Not for very long, I won't, if the process adds inefficiency or is designed to compensate for inadequacies of poor staff. Such companies do not do well, in the long run and I have no desire to be part of their downfall.
"What I usually find is that often I have to go back and correct someone else's work."
Which is annoying, but what does that have to
I didn't think I had to cite every reference... I've noted ratios of productivities within a team. Google for the appropiate documentation to back that up. But, basically, a 10% hit on someone who's 10 times more productive than average hurts a lot more than a 10% hit on someone who's average.
*This* is where tool support is useful. Set up Emacs/vim/whatever so that it implements in-house style rules. When you commit, checkstyle (or similar) runs and prompts you to fix formatting errors before the changes are accepted in the repo.
That would be good, yes... if the shop permitted this. However, the shops I've experienced with the most draconian formatting and layout rules also forbid the use of automated tools to support them! The shops with a more relaxed atmosphere, and a "recommended" style, generally encourage their use.
I remember a shop which required 120 pages of internal documentation for some 6000 lines of new code produced within 2 weeks. Well, doxygen is your friend here, and helped get the work done on time, with the support of all teammates, particularly those who used it before. Management, however, decided that using such a tool was "unproved" and "risky" and the work was to be redone manually, with now slip in schedule and a day left! This, after the fact, with excellent results (printed, and hyperlinked online docs). Needless to say, I buggered out of there pretty damn quick, to the dismay of those who would have liked me on their team (which was not permitted without the approval of one's current manager -- a real biggoted arsehole if I ever met one). Getting paid a nice bundle more, too.
These same kind of morons who will take a common coding style position and not consider the overhead of conforming to it. In extreme situations, the benefits often do not outweigh the costs. I'm called upon the "save the day" in just those kind of extreme conditions, when someone has, for example (this is a real world example), delivered 8000 lines of multithreaded Java code but was oblivious to the use of the "sychrinized" keyword, and that, gues what, doesn't work, with three days before an integration deadline. The last thing I will worry about is ensuring I adhere to a formatting style -- It's my job to make it work, on time -- never mind that I haven't seriously used Java before.
Is that how development should be done? No, of course not. In a "perfect" world, we'd have the luxury to take the time to adapt to what ever conventions exist. Unfortunately, development is far from perfect, and the best are usually called upon to clean up the dirtiest mess.
Your point appears to be that a common style improves communication and therefore productivity. That it does, but it is not the only thing that does so, and carries a burden of it's own. Better developers also adapt to differeing styles when necessary to read them. It's the writing that's a pain when you're in a crunch. When 90% of the work is making sure the i's are dotted and the t's are crossed, something is wrong. And this overhead increases with productivity.
Before I continue here, from the arguments you make, it has become clear you have worked on few projects where you had to interact with other people. In essense, it sounds like you would normally start working on a project and stop only when you feel like you have done enough for the day/night/whatever. It sounds like you work in an room, by yourself, without any communication with anyone else except at the start and end of the project.
It doesn't sound like you have been part of a team working on a product, or part of a team working on a component that gets used by other developers.
Lesse, ADAS+: 100+ developers in three locations; RMU75x: 8-16 developers delivering a test head to BT to teast "each pohone line, every night".
Once the task boundaries ar
That way, when someone gets a Red Hat distro, they know it's "official", if the law has been followed.
Yes, yes, that's a big "if". But it's a start: you can have the GPL and still restrict what others can pass off as an "official" version.
The next step, of course, is to have a trusted source sign the aggregate and important components thereof. That has the advantage that redistribution of the aggregate in toto does not have to be curtailed to make sure that each copy is legit.
- talking to other staff
Sigh.
I am not talking to other staff when, er, I'm not talking to other staff.
It should be obvious that one trivially reformats to a publication standard to discuss it.
The whole jist of your argument appears to be "don't work this way because it will reduce your productivity, and see, when you work that way, you are more productive than average." Experience has taught me that, no, it doesn't reduce my productivity just because it might reduce someone else'sm and if you left me alone, I'd be five times more productive still.
Disbilief of my assertions might be one thing, and understandable, but to ignore the proof when the pudding has been presented, is moronic.
I am not arguing that it is impossible to deal with a foreign formatting standard. I am arguing however that this (a) slows down implementation (counting spaces and looking up style rules just to open a new basic block), and (b) enough to have a noticible effect on productivity.
Perhaps you do not find typing speed an implementation bottleneck, but those of us who regularly crank out 20k lines of production quality code a month, do. For an 8 hour day, that's around 30 seconds per line of code. Stopping to worry about style is going to kill that by a noticible margin. At some point, one leaves the design phase and has to implement. The "how" answered, the "picture of the code" clear in one's mind, the last distraction one needs is "does this break style?"
And yes, I have the world class profitable shipping products under my belt to back those quality, and bravado assertions. You've probably used them if you make telephone calls.
Take some time to research productivity and quality metrics across professional developers some time: you'll find a one (some would argue as much as two) order of magnitude difference between best and average. Of course, if you've never been "in the zone", you would not believe this possible.
Right, so your contract doesn't specify how many hours you are expected to show up and do work?
No. It specifies what is to be done, and when it is to be delivered. If that means 10, 20, 40, 80, or 120 hours a week of work, so be it.
When salaried, the only metric is "ship what works on time", with the implied requirement "even if this means taking the time to fix other people's fuckups". Teamwork is not "everyone goes to the company-sponsored social event". It's "You drop the ball, I catch it."
In fact as a salaryman, if you are in the tech industry you're probably going to be required to work overtime without remuneration.
You don't get it, do you?
For a hard-core hacker, it isn't about overtime, or salary. Money is nice, of course, but I do what I'd do because I'd do it anyway. So, the concept of "overtime without remuneration" is meaningless -- the pleasure comes from the work. The compensation is a nice side effect that takes care of essential needs.
Is that an attitude ripe for employer abuse? Of course it is. However, abusive employers and managers soon find that there are plenty of employers out there who are not abusive, and when the time is right, it's "Adios!" The funny thing is that better working conditions have tended to go hand in hand with (substantially) more money. I've never encountered an enjoyable job that, otherwise, paid badly.
One can argue that "work is not life", but if you spend 30-50% of your time doing something, it better be something that you enjoy doing, and that, ultimately, work is, indeed, a major part of life.
I find more recent Red Hat distros (RH 8.0, FC1 and FC2) to be harder to install, configure, and use, than older ones (like RH 5.x through to 7.2).
I started with a Slackware predecessor (you know, the "A" series, "B" series, ... "X" series (that was a big one)) and am quite comfortable customizing /etc/... configuration files manually, at least the obvious ones. Sendmail is still a bit of "black magic for me", solely because I just "set it and forget it" and have not bothered to really study its arcane config files. Still, Google is your friend here. So, I'm not exatly a noob.
The trend from 5.x through 7.2 was one of improved installation, better device support, etc. More systems would work out of the box. Still, one had to look elsewere for support for modern printers, V4L was a dependency hell issue, and, eventually, the build tools were too out of date to even build all the fun stuff from source any more. Time to move on. I looked at FC1 and FC2. That's when the grief started!
Installing either was a no brainer, and automatic X configuration has gotten fairly good, but lo, FC2 would not get me into a graphical login despite setting the initial run state to 5. The frustrating thing was that startx appeared to work fine. It turned out to be a dependency issue on a DRI (I think) kernel module that was not loaded. Time to configure and build a custom kernel (and modules) for the box.
Now, I may have just been unlucky, but I didn't think an AIW video card was that obscure as to have this kind of problem. Anyway, I build a kernel, make an lilo.conf entry for it (still to lazy to pick up grub configuration -- it's on the list), reboot, and... yay! it's comming up..., no, wait, why is it hung probing for new hardware? Grrr.
Turns out I was a little too liberal in configuring the optional hardware in my kernel config. So, I take the opposite approach, enabling things I know I have or are known to be "safe". Well, this works better! Ah, even X comes up in run level 5.
Phew, that was a lot of unexpected work.
After running for a while, I notice that eventually the system hangs when I try to log in. It turns out that the nifty bits that change device ownership on graphical login (FWIW, I use Gnome) on the console sometimes don't change it back, or think that the last user hasn't released the console. This, in turn, causes something to wait forever trying to get the sound device.
Now, in fairness, I had a similar problem with RH 7.2 that I hadn't resolved, in that sound device ownership sometimes didn't get set to the current console user, but that didn't hold login up. There was nothing obvious to indicate what the problem was at first, either -- no "Sound device unavailabe, ignore?" popup, or other indication. Took a bit of digging to find it.
Perhaps I log out "wrong". I've used ctrl-alt-backspace for years. Did that become a bit too drastic at some point? Google or RH Bugzilla weren't too helpful here -- describing such login hangs, but generally not related to my specific symptoms.
In fairness, the "fancy" USB Epson CX6400 printer/scanner/copier was supported with minor configuration by both the printing system and SANE -- I'd had grief with a Canon BJC 2100 in the past for which Canon provided no helpful support, and reverse-engineered drivers were poor and didn't support the scanning mode at all. So, despite the encouraging research that it was well supported by the printing system and SANE, it was my first USB peripheral, and a bit of a leap of faith. (Hey, Fry's had it on sale). Of course, mature USB, printing, and scanning support were one of the reasons I moved to FC2 in the first place.
But, the login issue makes it fairly unusable for now -- the wife and kids still use RH 7.2. I suppose I could bypass the automatic device ownership on console login change and make them generously shared -- it's not like there will be contention for them, but it bugs me that an existin
Of course, if an Arrabica espresso isn't enough of a jolt for you, just make it a doppio (a double).
Personally, I prefer African coffees, and have a fondness for Kenya AA beans as far as run of the mill coffee goes, though many find them too strong (tastewise).
Now, who's smoking crack?
When developing, you reformat to your preference, and all debug information matches what you've got -- about the only time this breaks is if you've got external references to precompiled components with a different layout. But, even then, if that code requires your attention during a debug cycle, it's not hard to reformat and recompile. (This does presume that all source is available to you, and a preponderance to "build everything (that matters)" in a build cycle. That is less than ideal, of course, but typical as most shops don't bother with proper dependency checking to be confident enough to not have to build everything all the time).
There is a tradeoff in managaing code in multiple presentations, and, indeed, sometimes it is not "worth it". However, when adding large blocks of new code, the freedom to lay it out as one likes buys a lot of time.
When you're ready to checkin, you again reformat to the standard, and generate diffs as appropriate (if necessary). To share context diffs requires only two things: an original version in a known format, and a diff that applies to that format. With originals in standard and personal formats, and a modified version in one of the two formats, generating diffs to either original is trivial.
I suppose that one could make the argument that all that reformatting takes too long, and without an understanding of the toolchain, this might be true. But to presume that just because something is time consuming for one, or even many, means that it is time consuming for all is folly. Processes which improve productivity by 20% for 8/10 developers on a team are useless when they kill productivity by 90% for the other 2/10 developers who are already an order of magnitude more productive than the rest (and this is typical in a shop). Before: Productivity = 8 * 1 + 2 * 10 = 28. After: Productivity = 8 * 1 * 1.2 + 2 * 10 * (1-0.9) = 9.6 + 2.0 = 11.6. Ideally, you want to be in a situation where you get the 20% boost for the mob, but only take a 5% cut for the rest: 8 * 1 * 1.2 + 2 * 10 * (1-.05) = 9.6 + 19 = 28.6. But, even here, the slightest impediment to your "best" hurts a lot.
Gee, and the selfish mob expect you to do work for the hours they pay you for. How naive.
Incorrect.
A common empoloyer may. Furthermore I don't "work hours". I am either salaried or work on contract.
The problem does not stem from reasonable alternate formatting styles. The problem stems from a need to very rapidly contribute hundreds or thousands of lines of code to a project without getting bogged down in the details of a particular formatting style, or worse, a style that prevents some syntactically valid programs from being written.
Perhaps I have been lucky, but I have never had to suffer idiot managers or coworkers for very long. However I have met some real idiots in my day (like people who don't realize that sizeof adds to portability and does not detract from it).
In any case, I like to have an "out" that permits me to escape standards lunacy where necessary -- shops that insist on a presentation style yet refuse any type of automated tool to help achieve that style for example.
Draconian dictation of program formatting style is a sign of inflexibility that interferes with getting a job done and tends to go hand in hand with an inability for developers to handle abstract designs and OOD and OOP in general -- the common focus being an incapacity to generalize what "reasonable formatting" is, and so requ