I work on server-side business apps, so that colors my response. The single biggest error in business programming is probably underestimation or misunderstanding of relational databases. Used properly, the database takes on much of the burden of storing, indexing and searching the data and prohibiting the entry of inconsistent data, thereby lightening the load on the application programmer. It's generally best to make the database the center of gravity, and use the "host language" (perl/java/python) as a thin layer of authentication, validation, business rules and logging between the database and the network. To do this, you need a good understanding of:
database design. Read Graeme Simsion's Data Modeling Essentials. This explains how to analyze proposed and existing business activities and accurately reflect them in a database schema. Knowing a lot about SQL or Oracle is not a substitute! A strong schema forces the database to do much of the work for you. A weak schema reduces the database to expensive passive storage.
SQL. Read Joe Celko's SQL for Smarties. Work through the examples with Postgres or Oracle. (Knowledge is in the fingers.) Main benefit: the ability to craft a SELECT statement that generates a desired report with little or no postprocessing in the "host" language. On average, the database is going to be faster and less buggy at extracting, correlating and sorting data than any custom-written code. If you ever perform two SELECTs and knit the results together with custom code, your SQL knowledge may have room for improvement.
Geeks love introverted, clean, mathematical problems and hate ugly, fuzzy business-driven problems. That bias is reflected in the responses here - Knuth is the hands down favorite. While I don't dispute Knuth's value, the focus on algorithms reinforces the lamentable tendency to reinvent the database for each major application. The programmer with a knowledge of C and a head full of algorithms has in a sense a complete toolkit to take on the world, but the programmer with a high-level language and a relational database operates at higher leverage because he need not reinvent fundamental parts each time.
For example, I learned many sorts in school. I have never used any of them at work. Perl has a built-in quicksort, and SQL has ORDER BY. I think you can assume that more energy and expertise went into Oracle's implementation of ORDER BY than you can bring to bear on average on a homemade sort.
These Extreme Programmers certainly managed to hit your hot buttons. I've skimmed them in the store, and never really formed an opinion. You may have pushed me over the edge. But in fairness, consider the other side.
The only people I know who are implementing XP are at large, rigid, "software engineering" places. In such places, it's useless for employees to point out the obvious - "You're crippling us with red tape, UML diagrams, QA, specification, process. Just back off and we'll write the code." But XP puts a respectable and trendy cover on these obvious complaints, and makes them more palatable to management.
My favorite XP tidbit: one of the books (perhaps the one you bought) has a section at the back that tries to describe some kind of OO epiphany. The book was written as one Frame file per chapter, and the authors collaborated remotely. The author needed a way to mail his colleagues only the files that he had changed. Since he was obviously the first person in the Universe to face this problem, he worked out an Object-Oriented design including IIRC classes for File and Directory. Much of the work was necessitated by the weakness of his chosen langauge (smalltalk) at filesystem interaction. At this point the OO epiphany, which I've forgotten, occurred. It's good to know that you can become a programming guru without discovering CVS or find(1).
For Perl, I wouldn't bother with any kind of reference. Just find scripts that roughly do what you want and hack them; it's blind groping around, but that's the way Perl works. If you can't get it to work that way, you probably should be writing in something else other than Perl.
That technique works when first getting your feet wet with Perl or when writing throwaway scripts. If you copy and hack up high quality code, you'll learn good habits. Randal Schwartz and Tom Christiansen are good. Code worth copying has 'use strict;' and usually has warnings enabled (-w). And if your interest in Perl ends with quick, hacked-up scripts, nobody will complain. But just because you learned to play "Happy Birthday" on the piano, don't assume you've exhausted the capabilities of the instrument.
If you want to advance further, I recommend reading comp.lang.perl.misc for a few months. You'll go from being happy that there's a way to accomplish X through awareness of the many ways to accomplish X to a feel for the best way to accomplish X in a given situation. When I was going through this phase, a single post on clpm could send me on an all-night hacking, reading and learning session.
The only Perl book I can wholeheartedly recommend is Damian Conway's Object Oriented Perl, which I love despite my lack of OO religion.
Most people coming to computers and computer programming wrongly think that objects are either the best, or even the only, way to build abstractions.
Yes. There is a tendency for OO advocates to rewrite history and essentially claim that code was a disorganized mess before the advent of OO, or alternately taht all previous coding paradigms were simply OO by another name. In fact, most useful code in the real world is procedural C, using functions and data structures as the key abstractions.
Perl is agnostic about OO - the facilities are unobtrusively present. But it's easy to write C-style procedural code in Perl. And the grep, map, and sort functions support functional programming.
I pretty much expected some lawyer at MPAA/DVDCCA to call HP's legal department and warn them that an employee might be exposing them to liability. Whether there really is any liability or not, it's easiest for the company to put the brakes on.
And that's probably what happened.
Similarly, Cadence contractor James Hanna was fired for involvement in pro-Palestinian activism.
I'm not disagreeing with your larger point, but I notice a certain tendency among geeks to possibly misunderstand business events. Bankruptcy is not necessarily bad news for the executives and officers of a company. In fact, they may have planned the bankruptcy as a chance to sell off some assets cheap to friends or to other companies they control. I'm pretty sure that whoever actually cooked the books at Worldcom benefited substantially from the fraud and doesn't care at all if the company is bankrupt.
Likewise, separation from a company is not necessarily bad news for executives/officers/partners. There are frequently huge golden parachute payments. You point to the "death" of Arthur Andersen as if it's some cautionary tale to accountants - I doubt it. I think the partners made lots of money by selling diluted auditing, and always knew it couldn't last. They will move on to new accounting firms and continue their careers. Trying to translate misconduct into dollar terms doesn't work too well because the dollars belong to "the corporation" and the people making the decisions have no problem with "the corporation" losing money if they make money.
The small "competitors" selling DSL were not really DSL providers at all. That's the crux of the issue. They just wanted government to force the regional Bells to hand over their DSL services at (or below) cost so they could resell it.
Some ISP's use ILEC, Covad or Northpoint DSLAMs in the CO. Others locate their own DSLAMs in the CO, but must still depend on ILEC copper. In any event, the ISP-user circuit is only half the picture. The other half is the ISP's upstream connectivity and auxiliary services like mail/news/web. Since choice is possible in this sphere, choice should be available to users. When you pay the ILEC (Bell) for a consumer DSL circuit, part of the money goes to the DSL-related costs and part goes to the network-related costs. If the ILEC sells DSL circuits without upstream connectivity to competing ISP's, the price should naturally be lower than the price for DSL+connectivity.
So, different DSL offerings are not "the exact same service" even if they're all using the ILEC's wire and DSLAM. Most issues I've seen with DSL are not related to the wire/DSLAM part of the service, but to the upstream bandwidth and policy issues. The ILECs naturally build the cheapest network possible and impose narrow terms of service, reasoning that their consumers are not very critical. Other providers build better networks, have more friendly TOS, and charge more.
You ask for completely free competition. How would this work? Would everyone be allowed to run their cables on existing telephone poles? Or would everyone be allowed to plant their own set of poles or dig trenches as they see fit? Or does the government get to decide who can compete?
CBDTPA will reduce performance due to requiring a query to the DRM for every file access. How else is it possible for a DRM to decide whether or not the process calling the file has "legitimate" access to it?
CBDTPA is not specific about the technology used. I'm basing my answers on TCPA, the Trusted Computing Platform Technology and Palladium. There is no need for the OS to check extra perms on a file. The file is just a bunch of random numbers to the OS. When you want to actually play the file, an application makes a DRM call asking the hardware to decrypt it. There could be latency at that point, although the processing will probably be done in a small dedicated CPU. But if takes 20 msec between hitting PLAY and hearing sound out of the speakers, nobody will care. So, under TCPA the latency of non-DRM files is not affected.
Now if for some reason they want to restrict you from even copying that useless encrypted block of bits (which is pointless - you could always mount the disk on a non-DRM computer) they would need to add a simple perm check in the disk, controller, or OS or all three. I don't think it would add even a millisecond. How long do the existing Unix permission checks take?
While the EU will accept stupid experiments in government from the US, there has to be something for this for the EU politicians and/or bureaucrats at least.
I guess you know that the EU is working on the European Union Copyright Directive which among many, many other things enforces DMCA-style anti-circumvention law. I'll leave you to speculate on the motives of the decision-makers.
More to the point, the EU and Asian government being able to derive a differential advantage for their electronics companies because the US Congress did something absymally stupid by simply refraining from passing a law... where is this a problem for the EU or any Asian government?
The Hollings Bill would affect US markets, not US manufacturers. So if it really is cheaper to make non-DRM parts, and there really is a market for them, both US and non-US makers would make both flavors for both markets. If, as I suspect, it's cheaper to just make one kind, both US and non-US makers will make DRM parts for both markets.
Look at car safety - the US has high standards for side impact resistance and other things. This doesn't handicap US car makers relative to foreign car makers - anyone selling cars in the US has to meet the standards.
Of course this whole line of discussion sounds a bit out of touch in light of recent globalization - what is a US car maker anyhow? Honda in Marysville OH? Volkswagen in Mexico? Jaguar (owned by Ford, I think)?
it's not the same thing. A US government mandated DRM would probably have to be burned in to the vendor chips before purchse to achieve CBDTPA or Broadcast Working Group compliance.
If there's a need for regionalized DRM, imagine that Intel downloads the DRM program into the CPU and then blows a fuse, preventing further tampering. But I don't think there's much need for regionalization if the DRM is designed "sanely" - merely enable the optional playback of restricted content. The "insane" DRM, which tries to assess and control ALL content on the machine, would probably be regionalized because of its inconvenience if it ever exists.
So NAFTA may be the weak spot in the Hollings law. Thanks.
I hope so. So far the prominent cases are Metalclad, a US company that successfully sued Mexico for blocking them from dumping toxic waste in Mexico, and Methanex, a Canadian Methanol maker that is suing California for banning the MTBE additive in gasoline. It remains to be seen if the globalization crowd will ever oppose something like the entertainment industry. But if it decides to (for the sake of consistency, let's say) it will win.
The U.S. is not yet enforcing the DMCA in a serious way. Don't confuse that lack of interest with lack of enforcement capability. I don't know exactly how a US Attorney thinks, but I guess he looks for cases that are easy to try and could result in long sentences. If every DMCA case is going to be tried like 2600, they may not be worth prosecuting. But eventually some smart prosecutor will come up with an efficient MO for busting DMCA violations and it will ripple through the law enforcement community.
They do not need 100% effectiveness to be effective. When a certain number of (DeCSS|Free Software) folks have gone to prison, the rest will not feel so invincible. At this point, the vast majority of us will give up - and it's childish bragging to pretend otherwise.
Public terminals are no problem. At the least, the government can seize all the equipment at the location under two different theories: evidence, and civil asset forfeiture. If they want to go a step further, they could arrest the owner(s) of the establishment and charge them under a variety of statutes. The net effect of these actions (which would never actually need to be taken) would be to convince public terminal providers to keep a clear record of who used what machine when.
But wait - I shouldn't have answered you so specifically. Rather, I'd like to convince you that if enforcing the Hollings Bill becomes a national priority, and violators are hiding behind X, whatever X is, the investigators will find a way to crush/remove/penetrate X.
As for non-US countries, there will be rough uniformity of law throughout the developed world. DMCA is coming to Canada and the EU, and probably all other developed countries via globalization. If the Hollings Bill is accepted by the globalization community (WTO) it will become effectively worldwide. If it is rejected, it will eventually have to be repealed in the US.
I agree, though, that if Free Software is legal in Europe and illegal in the U.S., which might be true for several years of transition period, it will be relatively easy and risk-free to obtain it in the U.S.
FWIW, I guess that something like the Hollings Bill will eventually pass, but will probably exempt Free Software and possibly all software. DRM is most effectively done in hardware.
I would think it's obvious. Assuming that Free Software is literally banned, anyone distributing it commits a crime. So the obvious enforcement procedure is:
Search for free software using all the tools and techniques a geek would use. Security through obscurity won't help here.
Download it and make sure it really is Free Software and not a prank. Note the IP address.
Get a warrant and make the ISP identify the user.
Arrest and charge the user.
Variations:
Before arresting, sniff the user's traffic for a few months. You'll get tons of downloaders (who may or may not be worth prosecuting) and possibly find the source.
After arrest, offer the user a deal: reduced sentence if he helps nab three more distributors. Or total immunity if he helps catch the software author.
Governments have been attacking clandestine networks since the dawn of time. The techniques are obvious. This type of law enforcement is shooting fish in a barrel.
...or move off-shore, to a place where your government has no influence...
Why isn't DeCSS already hosted in such a place? Because there is no such place. US influence reaches more places than the internet does.
You're right that the "high-tech" industry is much bigger than the entertainment industry. But I think it's unlikely that passage of the Hollings bill would hurt the US tech industry. First of all, it would soon spread to most countries via WTO, WIPO, TRIPS, etc. Second, it's not that big a deal for hardware designers to incorporate a licensed protection technology. In the overall complexity of a powerful video card, for instance, this tech might add 5% to the complexity.
Electronics makers already adapt to a variety of regional laws. Many countries have different laws about the physical limits on Ham radios. So some radios have the ability to load the allowed spectrum map externally. That way they are always localized correctly to the country.
Now if the Hollings bill passes and is NOT ratified by the globalization crowd, a Canadian or Mexican manufacturer could sue the US under NAFTA. NAFTA says that a government regulation blocking imported goods must not be any more restrictive than necessary for the purpose. WTO makes the call, and they can strike down the law.
The point is not to replace "bad" legislators with "good" legislators. That distinction is childish. The point is to show legislators and candidates that they can earn money, votes and campaign assistance by embracing our agenda. Remember, the most powerful voter is one equally likely to vote either way. If you're 99% likely to vote for Alice because you consider Bob evil, then neither Alice nor Bob have any reason to listen to you.
Reading these comments is frustrating because slashdotters are so far from understanding politics. Not that I'm any expert.
Let me know if there's anyone from Nebraska you'd like me to vote against. (But they all seem to be focused on corn & stuff instead of anything tech-related)
This is the politics of reaction, which seems all too popular on/. - lets punish or reward some pol for a past action, presumably sending a message to other pols. Incredibly unlikely to work. Don't wait for the guy to screw up and then vote against him. If your pols haven't taken a position yet on the Hollings bill, maybe you can organize with other like-minded local geeks and offer a nice chunk of money, votes and campaign volunteers if the pol will oppose the bill.
Your senator's focus on corn means that he might actually listen to you about DRM, because to him it's a side issue. In contrast, Diane Feinstein or Fritz Hollings are deeply committed to their cause and will not be easily swayed by voters or contributions.
Here's what struck me on a first read through the FUD page:
ZDNet also noted that Red Hats High Availability Server also "lacks content replication support", a critical feature for Web server appliances in Web farms.
What are they talking about? The only web server appliances I've seen are Cobalt Cubes and Raqs, which are used by the tiniest, least sophisticated web sites. While the hosting provider frequently has a large number of these (a "farm"?) they are not serving the same content. Is there any place in which "content replication" and "web appliance" coincide? In my (limited) experience, anyone with enough web servers to care about "content replication" is using either ordinary PC's or Suns. In any event, "content replication" is easily handled with rsync.
Elsewhere in the document I found the phrase integrated application integration. I can only conclude that the author has gorged himself on buzzwords and succumbed to FUD poisoning.
Linux offers no reliability framework to enhance system reliability.
Would it be unfair in this context for me to report what happened when I tried to post a comment to the varbusiness story? I got:
Response object
error 'ASP 0158 : 80004005'
Missing URL/Components/Talkback/posttalkback.asp, line 84
A URL is required.
If your car has major structural flaws due to faulty engineering and shoddy workmanship, would you weld a "reliability framework" of 2" pipe around it? Or just get rid of it?
Then we return to Microsoft's phobia of GPL virality:
An NVIDIA programmer, in the course of developing a driver for one of its products, used a portion of code from a freely available video driver. The developer failed to realize the code was licensed under the GPL and would therefore require NVIDIA to release the source code for its entire driver. Because NVIDIA did not want to release the source code to its commercial software, the company incurred substantial cost to develop a new driver that did not contain the GPL code.
Implication: if the accidentally included code belonged to Microsoft, NVIDIA would have been allowed to incorporate it for free, and would not have "incurred substantial cost". I doubt that. Anyhow, this whining about "substantial cost" implies that the owners of the (non)plagiarized code somehow victimized NVIDIA. This is like saying that since you wouldn't lend me your car for my upcoming vacation, I "incurred substantial cost" renting one.
Linux uses clear text for authentication, does not allow the configurations of individual permissions to the file level and does native support standard encryption technologies such as Kerberos version 5.0.
Linux supports many kinds of authentication via PAM. The only uses of clear text authentication I can think of are telnet, ftp and r*. Any OS supporting these legacy protocols must necessarily allow clear text authentication.
I think the complaint about "configurations of individual permissions" refers to some additional refinement of permissions in Windows. In reality, the Unix permissions scheme adapts fairly well to real-world issues, providing good security without too much inconvenience. The Windows permission scheme, in contrast, appears over-complicated, poorly understood by Windows admins, and frequently ignored/bypassed.
Any encryption natively supported by Windows, except for the simplest symmetric cipher implementations, is highly suspect. Not being subject to peer review, it could contain accidental or deliberate weaknesses that reduce the entropy of keys of leak portions of key material. It is well known that the NSA puts pressure on commercial vendors to introduce back doors - they did so with Crypto AG and Gretag.
I'm not sure the FUD-filled utterances of Microsoft deserve this level of scrutiny. They are aiming for that narrow group of "appliance" OEM's who are so lacking in skills and self-confidence that they might cave and pay Microsoft for protection.
Geeks have always been reluctant to take this threat seriously. Even now, as Microsoft builds up steam for this multi-year war, many people are naively proclaiming that "users won't stand for it" or that some technical flaw will topple the whole thing. I can't address all the naive objections I've seen, but to summarize: this is a carefully laid trap. There are no obvious escape holes.
I do want to address the notion that "we", the imagined unified group of computer buyers, will "rebel" against Pd. Pd will not (immediately at least) remove any capabilities from the computer - it will add capabilities, such as the ability to download RIAA music videos. So from the home user's standpoint, it's a net gain. I don't have to explain the MPAA/RIAA's case - you already know how much they'll like it.
The underemphasized fact is that Pd will satisfy a deep craving of corporate users. Corporations yearn to send documents which can't be copied or retained. Bill Gates knows this, and knows that it's more important than all the entertainment applications combined.
History and accountability are enemies of the modern corporation on many levels. A vendor might want to submit a proposal but prevent the proposal from being recycled. A company might want to alter its "mission statement" without leaving any proof that it was once different. Even where there is no particular reason to control the flow of information, corporations will choose to do so if they can.
Now imagine the future. All the techno-illiterate (think HR, management, customers if you're a contractor) use Palladium and send you encrypted documents without even realizing it. They don't even have the ability to send plaintext, because their corporate policy prevents it, even if they knew what you were talking about. Without Pd, you are cut off from the non-geek world.
To those who claim a chicken-and-egg problem (I can't believe you need to be told this, but...) the process will start with Pd systems happily interoperating with "legacy" systems. Once Pd. reaches something like 40% in the business world, the screws are tightened and non-Pd start to feel some pain. They may have to run a special "viewer" app that's resource-intensive and crash-happy. As the Pd. percentage increases, the screws are tightened more. No different from the carefully tuned incompatibilities in Office file formats. Microsoft is good at this.
With the number of customers Earthlink has, can you really expect them to always keep *every* user with an open-relay off of their network? Even if they hired whole teams of people just to perform that one task, new people with open-relays would subscribe faster than they could discover them. Hence, Earthlink would almost always be on a blacklist.
First, I checked Earthlink's main web and mail IP's (as representatives) and they seem to be on only one blacklist: blars.org.
Second, the only thing expected of ISP's is that they read their abuse mail at least once a day and upon verifying abuse they promptly terminate the accounts in question. ISP's need abuse departments, and the more accounts the ISP has the more people it needs in its abuse department. The abuse department does not need to discover open relays or other network abuse; it merely needs to read, investigate, and act on complaints.
Failure to maintain an effective abuse department will result in the network becoming a haven for abusers, and that will cause the ISP's netblocks to be blacklisted.
Dilbert is funny. Tom Tomorrow is not funny - but he may be trying to be funny. Scott Adams has a keen ear for workplace idiocy. Tom Tomorrow does not have much feel for how people really talk and act - his characters are overblown caricatures.
TT seems to think that if office workers read the right kind of comics they'd rise up in some Marxist revolution against the oppressors.
The solution to the Dilbert workplace is not some kind of revolution. Rather, go work for a better company. The only reason intelligent people stay in the Dilbert-style workplace is fear, or lack of awareness of alternatives. The best antidote is to maximize savings and avoid debt.
If I can presume to speak for the Dilbert constituency, we are not communists. We are clear-eyed realists. We don't want our employer to be nice, or to care about us, or to provide jobs for life. We simply want high pay, reasonable hours, respect, clearly defined tasks or responsibilities, and freedom from irrational interference. And (knock on wood) I have been able to get these things.
This argument is inconsistent. You legitimize DeCSS because it helps people use "legally owned" DVDs. This implies that the law is the source of your morality. But distributing DeCSS is illegal, a violation of the DMCA. So obviously you have less respect for the DMCA than for traditional copyright. Therefore, whether something is legal is not really your criterion.
What software are you using? I'm guessing that shift-END = "end of document" and shift-HOME = "start of document". In vi, those are respectively "G" and "1G".No need to remove the hands from home row. And we use 'hjkl' instead of arrows.
This problem is not unique to DRM. Many systems rely on keeping important keys secret. For example, Ross Anderson has written about the problem of crypto keys used by ATMs. And when the US was pushing the Clipper chip, they had a scheme for inserting the eavesdropping key which seemed fairly robust. I think the usual approach is to design an automated system for generating and handling the keys so employees never come in contact with them. I think Intel already successfully keeps a lot of secrets. For these keys to leak, either there would be a breakdown in internal procedures or an employee would have taken great risks to circumvent security and copy the keys.
But in general, I take your point that this scheme puts a lot of eggs in one basket.
The transport and negotiation methods are not the limiting factor. Once again, there are already standards for doing this stuff.
Actually, they are the limiting factor. Incredibly, getting two companies' financial systems talking over the wire remains a project, an implementation. By now it should be totally casual - a small vendor should click "invoice" in QuickBooks and the invoice should immediately show up in ACME corp's ERP system. But the incredible stupidity and inertia of industry have retarded this. Microsoft is hoping to drag everyone into the modern age by labelling a specific kind of XML messages "web services" so even PHBs understand the simple proposition.
Microsoft has enormous clout with software vendors. If every ERP/Accounting app supports the exact same protocols, the impact will be huge.
The dynamically-typed languages are very useful and powerful for individual programmers, smart programmers, and small, tightly-knit teams. But static typing is an important feature in the commercial world, where software has to be worked on by ever-changing teams of often mediocre people.
You could be right. Having only worked in small teams of smart programmers, I haven't seen it yet. I guess you're describing this: Vlad has a variable $packets_received, which he thinks of as an integer. He increments it for each packet received. Six months later, Raji adds a line: $packets_received = 'NO'. Later in Vlad's code, we find if($packets_received)... and since a non-numeric string evaluates as 1 in perl, we have a bug that could be prevents by static typing.
But the way I think Perl solves this is with the Package namespace. Variables generally stay in their packages, which should be kept small, or at a lower scope. Of course I have seen plenty of awful older Perl where global variables ran from file to file like wild animals leaving chaos in their wake.
Anyhow, if there is a benefit to typing, the types furnished by Java are not very useful to business apps. Sure, it's nice to distinguish a float, int and string, but how about a zipcode, account number, iso country code? The only way to achieve that level of typing (in Perl and I guess in Java) is to make the variable an instantiation of a class which overrides the assignment operator. For some reason, this hasn't felt worthwhile (I guess because we haven't encountered the Vlad/Raji error above).
But another reason is that we try to keep code generic. There's not likely to be a $zip_code variable in much of my code, because zip_code is just one field in a table. Dynamic typing allows Perl data structures to effortlessly reflect info from databases. For example, several XML APIs I've written perform a SELECT, compute some derived values, and return the whole thing as XML. If columns are added to one of the tables in the SELECT, my code is not affected. Casting todays schema in concrete is not a smart move for maintainability.
I hear this all the time from Lisp fans. But if it's true that Java, Perl, Python and XML are trivial variations on Lisp ideas, why didn't the Lispers make a bigger impact? Since Lisp was around long before these "variant" technologies, why isn't the majority of the web running on Lisp?
I can only think of two answers:
The specific elements the Lispers are so proud of (s-expressions, etc.) are not the whole story. They are relatively minor constituents of these modern and popular technologies.
The Lisp community had little interest in real-world needs, and did not evolve or promote Lisp as a solution to those needs. Those who evolved and promoted such solutions deservedly got the fame and market share.
The way I see it, the only way we are having this discussion at all is thanks to C, Perl, Linux, and possibly Microsoft (not on my end).
Again, you have no understanding of the technology. CSV is a format that says 'here is some data'. XML says 'here is some data, and a description of what that data means'. Please dont post on a subject you are obviously clueless about.
I have to arrange automated data transfer from our systems to several new and old systems. When arranging automated data interchange, I first offer XML. The recipient usually responds that while he could parse XML, it would require a commercial product or extra programmer time. Could I please send tab or comma delimited instead? Despite all the XML buzz, the humble delimited file remains the workhorse of inter-platform data transport in the business world.
CSV can have a header row which assigns names to the columns. This is equivalent to element names in XML. It is not correct that XML assigns meaning to data and CSV doesn't. The real benefit of XML, as I see it, is that while delimited files represent two-dimensional information (entity/attribute) XML can represent multi-dimensional info - an entity can contain child entities.
I work with Apache and mod_perl. We use the Apache::Session module for persistence. It can backend to files or a database. Caching some info from the database in the session is a tradeoff. It speeds up the app by reducing SELECTs. However there is a risk that the underlying data changes and the user sees the old data.
In the case of an e-commerce app a while back, we cached product info for the items in the cart. What if a price changed between the item entering the cart and checkout? We agreed that the customer should pay the "old" price. However, if the item was no longer available, the customer would have to be told.
The underlying mechanism of persistence is quite simple and can be implemented in any real programming language. I have no idea why anyone makes a big deal about it. Maybe I only think that because of the fluidity of Perl's data structures - it's a no-brainer for us to create arbitrary "trees" of data, serialize and deserialize them.
Slashdot Mirror
- database design. Read Graeme Simsion's Data Modeling Essentials. This explains how to analyze proposed and existing business activities and accurately reflect them in a database schema. Knowing a lot about SQL or Oracle is not a substitute! A strong schema forces the database to do much of the work for you. A weak schema reduces the database to expensive passive storage.
- SQL. Read Joe Celko's SQL for Smarties. Work through the examples with Postgres or Oracle. (Knowledge is in the fingers.) Main benefit: the ability to craft a SELECT statement that generates a desired report with little or no postprocessing in the "host" language. On average, the database is going to be faster and less buggy at extracting, correlating and sorting data than any custom-written code. If you ever perform two SELECTs and knit the results together with custom code, your SQL knowledge may have room for improvement.
Geeks love introverted, clean, mathematical problems and hate ugly, fuzzy business-driven problems. That bias is reflected in the responses here - Knuth is the hands down favorite. While I don't dispute Knuth's value, the focus on algorithms reinforces the lamentable tendency to reinvent the database for each major application. The programmer with a knowledge of C and a head full of algorithms has in a sense a complete toolkit to take on the world, but the programmer with a high-level language and a relational database operates at higher leverage because he need not reinvent fundamental parts each time.For example, I learned many sorts in school. I have never used any of them at work. Perl has a built-in quicksort, and SQL has ORDER BY. I think you can assume that more energy and expertise went into Oracle's implementation of ORDER BY than you can bring to bear on average on a homemade sort.
These Extreme Programmers certainly managed to hit your hot buttons. I've skimmed them in the store, and never really formed an opinion. You may have pushed me over the edge. But in fairness, consider the other side.
The only people I know who are implementing XP are at large, rigid, "software engineering" places. In such places, it's useless for employees to point out the obvious - "You're crippling us with red tape, UML diagrams, QA, specification, process. Just back off and we'll write the code." But XP puts a respectable and trendy cover on these obvious complaints, and makes them more palatable to management.
My favorite XP tidbit: one of the books (perhaps the one you bought) has a section at the back that tries to describe some kind of OO epiphany. The book was written as one Frame file per chapter, and the authors collaborated remotely. The author needed a way to mail his colleagues only the files that he had changed. Since he was obviously the first person in the Universe to face this problem, he worked out an Object-Oriented design including IIRC classes for File and Directory. Much of the work was necessitated by the weakness of his chosen langauge (smalltalk) at filesystem interaction. At this point the OO epiphany, which I've forgotten, occurred. It's good to know that you can become a programming guru without discovering CVS or find(1).
If you want to advance further, I recommend reading comp.lang.perl.misc for a few months. You'll go from being happy that there's a way to accomplish X through awareness of the many ways to accomplish X to a feel for the best way to accomplish X in a given situation. When I was going through this phase, a single post on clpm could send me on an all-night hacking, reading and learning session.
The only Perl book I can wholeheartedly recommend is Damian Conway's Object Oriented Perl, which I love despite my lack of OO religion. Yes. There is a tendency for OO advocates to rewrite history and essentially claim that code was a disorganized mess before the advent of OO, or alternately taht all previous coding paradigms were simply OO by another name. In fact, most useful code in the real world is procedural C, using functions and data structures as the key abstractions.
Perl is agnostic about OO - the facilities are unobtrusively present. But it's easy to write C-style procedural code in Perl. And the grep, map, and sort functions support functional programming.
I pretty much expected some lawyer at MPAA/DVDCCA to call HP's legal department and warn them that an employee might be exposing them to liability. Whether there really is any liability or not, it's easiest for the company to put the brakes on.
And that's probably what happened.
Similarly, Cadence contractor James Hanna was fired for involvement in pro-Palestinian activism.
I'm not disagreeing with your larger point, but I notice a certain tendency among geeks to possibly misunderstand business events. Bankruptcy is not necessarily bad news for the executives and officers of a company. In fact, they may have planned the bankruptcy as a chance to sell off some assets cheap to friends or to other companies they control. I'm pretty sure that whoever actually cooked the books at Worldcom benefited substantially from the fraud and doesn't care at all if the company is bankrupt.
Likewise, separation from a company is not necessarily bad news for executives/officers/partners. There are frequently huge golden parachute payments. You point to the "death" of Arthur Andersen as if it's some cautionary tale to accountants - I doubt it. I think the partners made lots of money by selling diluted auditing, and always knew it couldn't last. They will move on to new accounting firms and continue their careers. Trying to translate misconduct into dollar terms doesn't work too well because the dollars belong to "the corporation" and the people making the decisions have no problem with "the corporation" losing money if they make money.
So, different DSL offerings are not "the exact same service" even if they're all using the ILEC's wire and DSLAM. Most issues I've seen with DSL are not related to the wire/DSLAM part of the service, but to the upstream bandwidth and policy issues. The ILECs naturally build the cheapest network possible and impose narrow terms of service, reasoning that their consumers are not very critical. Other providers build better networks, have more friendly TOS, and charge more.
You ask for completely free competition. How would this work? Would everyone be allowed to run their cables on existing telephone poles? Or would everyone be allowed to plant their own set of poles or dig trenches as they see fit? Or does the government get to decide who can compete?
Now if for some reason they want to restrict you from even copying that useless encrypted block of bits (which is pointless - you could always mount the disk on a non-DRM computer) they would need to add a simple perm check in the disk, controller, or OS or all three. I don't think it would add even a millisecond. How long do the existing Unix permission checks take? I guess you know that the EU is working on the European Union Copyright Directive which among many, many other things enforces DMCA-style anti-circumvention law. I'll leave you to speculate on the motives of the decision-makers. The Hollings Bill would affect US markets, not US manufacturers. So if it really is cheaper to make non-DRM parts, and there really is a market for them, both US and non-US makers would make both flavors for both markets. If, as I suspect, it's cheaper to just make one kind, both US and non-US makers will make DRM parts for both markets.
Look at car safety - the US has high standards for side impact resistance and other things. This doesn't handicap US car makers relative to foreign car makers - anyone selling cars in the US has to meet the standards.
Of course this whole line of discussion sounds a bit out of touch in light of recent globalization - what is a US car maker anyhow? Honda in Marysville OH? Volkswagen in Mexico? Jaguar (owned by Ford, I think)?
If there's a need for regionalized DRM, imagine that Intel downloads the DRM program into the CPU and then blows a fuse, preventing further tampering. But I don't think there's much need for regionalization if the DRM is designed "sanely" - merely enable the optional playback of restricted content. The "insane" DRM, which tries to assess and control ALL content on the machine, would probably be regionalized because of its inconvenience if it ever exists. I hope so. So far the prominent cases are Metalclad, a US company that successfully sued Mexico for blocking them from dumping toxic waste in Mexico, and Methanex, a Canadian Methanol maker that is suing California for banning the MTBE additive in gasoline. It remains to be seen if the globalization crowd will ever oppose something like the entertainment industry. But if it decides to (for the sake of consistency, let's say) it will win.
The U.S. is not yet enforcing the DMCA in a serious way. Don't confuse that lack of interest with lack of enforcement capability. I don't know exactly how a US Attorney thinks, but I guess he looks for cases that are easy to try and could result in long sentences. If every DMCA case is going to be tried like 2600, they may not be worth prosecuting. But eventually some smart prosecutor will come up with an efficient MO for busting DMCA violations and it will ripple through the law enforcement community.
They do not need 100% effectiveness to be effective. When a certain number of (DeCSS|Free Software) folks have gone to prison, the rest will not feel so invincible. At this point, the vast majority of us will give up - and it's childish bragging to pretend otherwise.
Public terminals are no problem. At the least, the government can seize all the equipment at the location under two different theories: evidence, and civil asset forfeiture. If they want to go a step further, they could arrest the owner(s) of the establishment and charge them under a variety of statutes. The net effect of these actions (which would never actually need to be taken) would be to convince public terminal providers to keep a clear record of who used what machine when.
But wait - I shouldn't have answered you so specifically. Rather, I'd like to convince you that if enforcing the Hollings Bill becomes a national priority, and violators are hiding behind X, whatever X is, the investigators will find a way to crush/remove/penetrate X.
As for non-US countries, there will be rough uniformity of law throughout the developed world. DMCA is coming to Canada and the EU, and probably all other developed countries via globalization. If the Hollings Bill is accepted by the globalization community (WTO) it will become effectively worldwide. If it is rejected, it will eventually have to be repealed in the US.
I agree, though, that if Free Software is legal in Europe and illegal in the U.S., which might be true for several years of transition period, it will be relatively easy and risk-free to obtain it in the U.S.
FWIW, I guess that something like the Hollings Bill will eventually pass, but will probably exempt Free Software and possibly all software. DRM is most effectively done in hardware.
- Search for free software using all the tools and techniques a geek would use. Security through obscurity won't help here.
- Download it and make sure it really is Free Software and not a prank. Note the IP address.
- Get a warrant and make the ISP identify the user.
- Arrest and charge the user.
Variations:- Before arresting, sniff the user's traffic for a few months. You'll get tons of downloaders (who may or may not be worth prosecuting) and possibly find the source.
- After arrest, offer the user a deal: reduced sentence if he helps nab three more distributors. Or total immunity if he helps catch the software author.
Governments have been attacking clandestine networks since the dawn of time. The techniques are obvious. This type of law enforcement is shooting fish in a barrel. Why isn't DeCSS already hosted in such a place? Because there is no such place. US influence reaches more places than the internet does.You're right that the "high-tech" industry is much bigger than the entertainment industry. But I think it's unlikely that passage of the Hollings bill would hurt the US tech industry. First of all, it would soon spread to most countries via WTO, WIPO, TRIPS, etc. Second, it's not that big a deal for hardware designers to incorporate a licensed protection technology. In the overall complexity of a powerful video card, for instance, this tech might add 5% to the complexity.
Electronics makers already adapt to a variety of regional laws. Many countries have different laws about the physical limits on Ham radios. So some radios have the ability to load the allowed spectrum map externally. That way they are always localized correctly to the country.
Now if the Hollings bill passes and is NOT ratified by the globalization crowd, a Canadian or Mexican manufacturer could sue the US under NAFTA. NAFTA says that a government regulation blocking imported goods must not be any more restrictive than necessary for the purpose. WTO makes the call, and they can strike down the law.
The point is not to replace "bad" legislators with "good" legislators. That distinction is childish. The point is to show legislators and candidates that they can earn money, votes and campaign assistance by embracing our agenda. Remember, the most powerful voter is one equally likely to vote either way. If you're 99% likely to vote for Alice because you consider Bob evil, then neither Alice nor Bob have any reason to listen to you.
Your senator's focus on corn means that he might actually listen to you about DRM, because to him it's a side issue. In contrast, Diane Feinstein or Fritz Hollings are deeply committed to their cause and will not be easily swayed by voters or contributions.
Elsewhere in the document I found the phrase integrated application integration. I can only conclude that the author has gorged himself on buzzwords and succumbed to FUD poisoning.
Would it be unfair in this context for me to report what happened when I tried to post a comment to the varbusiness story? I got: If your car has major structural flaws due to faulty engineering and shoddy workmanship, would you weld a "reliability framework" of 2" pipe around it? Or just get rid of it?
Then we return to Microsoft's phobia of GPL virality: Implication: if the accidentally included code belonged to Microsoft, NVIDIA would have been allowed to incorporate it for free, and would not have "incurred substantial cost". I doubt that. Anyhow, this whining about "substantial cost" implies that the owners of the (non)plagiarized code somehow victimized NVIDIA. This is like saying that since you wouldn't lend me your car for my upcoming vacation, I "incurred substantial cost" renting one.
- Linux supports many kinds of authentication via PAM. The only uses of clear text authentication I can think of are telnet, ftp and r*. Any OS supporting these legacy protocols must necessarily allow clear text authentication.
- I think the complaint about "configurations of individual permissions" refers to some additional refinement of permissions in Windows. In reality, the Unix permissions scheme adapts fairly well to real-world issues, providing good security without too much inconvenience. The Windows permission scheme, in contrast, appears over-complicated, poorly understood by Windows admins, and frequently ignored/bypassed.
- Any encryption natively supported by Windows, except for the simplest symmetric cipher implementations, is highly suspect. Not being subject to peer review, it could contain accidental or deliberate weaknesses that reduce the entropy of keys of leak portions of key material. It is well known that the NSA puts pressure on commercial vendors to introduce back doors - they did so with Crypto AG and Gretag.
I'm not sure the FUD-filled utterances of Microsoft deserve this level of scrutiny. They are aiming for that narrow group of "appliance" OEM's who are so lacking in skills and self-confidence that they might cave and pay Microsoft for protection.Geeks have always been reluctant to take this threat seriously. Even now, as Microsoft builds up steam for this multi-year war, many people are naively proclaiming that "users won't stand for it" or that some technical flaw will topple the whole thing. I can't address all the naive objections I've seen, but to summarize: this is a carefully laid trap. There are no obvious escape holes.
I do want to address the notion that "we", the imagined unified group of computer buyers, will "rebel" against Pd. Pd will not (immediately at least) remove any capabilities from the computer - it will add capabilities, such as the ability to download RIAA music videos. So from the home user's standpoint, it's a net gain. I don't have to explain the MPAA/RIAA's case - you already know how much they'll like it.
The underemphasized fact is that Pd will satisfy a deep craving of corporate users. Corporations yearn to send documents which can't be copied or retained. Bill Gates knows this, and knows that it's more important than all the entertainment applications combined.
History and accountability are enemies of the modern corporation on many levels. A vendor might want to submit a proposal but prevent the proposal from being recycled. A company might want to alter its "mission statement" without leaving any proof that it was once different. Even where there is no particular reason to control the flow of information, corporations will choose to do so if they can.
Now imagine the future. All the techno-illiterate (think HR, management, customers if you're a contractor) use Palladium and send you encrypted documents without even realizing it. They don't even have the ability to send plaintext, because their corporate policy prevents it, even if they knew what you were talking about. Without Pd, you are cut off from the non-geek world.
To those who claim a chicken-and-egg problem (I can't believe you need to be told this, but...) the process will start with Pd systems happily interoperating with "legacy" systems. Once Pd. reaches something like 40% in the business world, the screws are tightened and non-Pd start to feel some pain. They may have to run a special "viewer" app that's resource-intensive and crash-happy. As the Pd. percentage increases, the screws are tightened more. No different from the carefully tuned incompatibilities in Office file formats. Microsoft is good at this.
Second, the only thing expected of ISP's is that they read their abuse mail at least once a day and upon verifying abuse they promptly terminate the accounts in question. ISP's need abuse departments, and the more accounts the ISP has the more people it needs in its abuse department. The abuse department does not need to discover open relays or other network abuse; it merely needs to read, investigate, and act on complaints.
Failure to maintain an effective abuse department will result in the network becoming a haven for abusers, and that will cause the ISP's netblocks to be blacklisted.
Dilbert is funny. Tom Tomorrow is not funny - but he may be trying to be funny. Scott Adams has a keen ear for workplace idiocy. Tom Tomorrow does not have much feel for how people really talk and act - his characters are overblown caricatures.
TT seems to think that if office workers read the right kind of comics they'd rise up in some Marxist revolution against the oppressors.
The solution to the Dilbert workplace is not some kind of revolution. Rather, go work for a better company. The only reason intelligent people stay in the Dilbert-style workplace is fear, or lack of awareness of alternatives. The best antidote is to maximize savings and avoid debt.
If I can presume to speak for the Dilbert constituency, we are not communists. We are clear-eyed realists. We don't want our employer to be nice, or to care about us, or to provide jobs for life. We simply want high pay, reasonable hours, respect, clearly defined tasks or responsibilities, and freedom from irrational interference. And (knock on wood) I have been able to get these things.
This argument is inconsistent. You legitimize DeCSS because it helps people use "legally owned" DVDs. This implies that the law is the source of your morality. But distributing DeCSS is illegal, a violation of the DMCA. So obviously you have less respect for the DMCA than for traditional copyright. Therefore, whether something is legal is not really your criterion.
What software are you using? I'm guessing that shift-END = "end of document" and shift-HOME = "start of document". In vi, those are respectively "G" and "1G".No need to remove the hands from home row. And we use 'hjkl' instead of arrows.
<bill status="proposed" name="CBDTPA">
<sponsor name="Fritz Hollings" constituency="Disney">
<violatesAmendment number="1">
<violatesAmendment number="4">
<contribution donor="Disney" amount="24500.00">
<contribution donor="AOL" amount="33000.00">
<contribution donor="National Association of Broadcasters" amount="25000.00">
<excuse>Promote broadband adoption</excuse>
<excuse>Save the arts from extinction</excuse>
</bill>
This problem is not unique to DRM. Many systems rely on keeping important keys secret. For example, Ross Anderson has written about the problem of crypto keys used by ATMs. And when the US was pushing the Clipper chip, they had a scheme for inserting the eavesdropping key which seemed fairly robust. I think the usual approach is to design an automated system for generating and handling the keys so employees never come in contact with them. I think Intel already successfully keeps a lot of secrets. For these keys to leak, either there would be a breakdown in internal procedures or an employee would have taken great risks to circumvent security and copy the keys.
But in general, I take your point that this scheme puts a lot of eggs in one basket.
Microsoft has enormous clout with software vendors. If every ERP/Accounting app supports the exact same protocols, the impact will be huge.
But the way I think Perl solves this is with the Package namespace. Variables generally stay in their packages, which should be kept small, or at a lower scope. Of course I have seen plenty of awful older Perl where global variables ran from file to file like wild animals leaving chaos in their wake.
Anyhow, if there is a benefit to typing, the types furnished by Java are not very useful to business apps. Sure, it's nice to distinguish a float, int and string, but how about a zipcode, account number, iso country code? The only way to achieve that level of typing (in Perl and I guess in Java) is to make the variable an instantiation of a class which overrides the assignment operator. For some reason, this hasn't felt worthwhile (I guess because we haven't encountered the Vlad/Raji error above).
But another reason is that we try to keep code generic. There's not likely to be a $zip_code variable in much of my code, because zip_code is just one field in a table. Dynamic typing allows Perl data structures to effortlessly reflect info from databases. For example, several XML APIs I've written perform a SELECT, compute some derived values, and return the whole thing as XML. If columns are added to one of the tables in the SELECT, my code is not affected. Casting todays schema in concrete is not a smart move for maintainability.
I can only think of two answers:
- The specific elements the Lispers are so proud of (s-expressions, etc.)
- The Lisp community had little interest in real-world needs, and did not evolve or promote Lisp as a solution to those needs. Those who evolved and promoted such solutions deservedly got the fame and market share.
The way I see it, the only way we are having this discussion at all is thanks to C, Perl, Linux, and possibly Microsoft (not on my end).are not the whole story. They are relatively minor constituents of these modern and popular technologies.
CSV can have a header row which assigns names to the columns. This is equivalent to element names in XML. It is not correct that XML assigns meaning to data and CSV doesn't. The real benefit of XML, as I see it, is that while delimited files represent two-dimensional information (entity/attribute) XML can represent multi-dimensional info - an entity can contain child entities.
I work with Apache and mod_perl. We use the Apache::Session module for persistence. It can backend to files or a database. Caching some info from the database in the session is a tradeoff. It speeds up the app by reducing SELECTs. However there is a risk that the underlying data changes and the user sees the old data.
In the case of an e-commerce app a while back, we cached product info for the items in the cart. What if a price changed between the item entering the cart and checkout? We agreed that the customer should pay the "old" price. However, if the item was no longer available, the customer would have to be told.
The underlying mechanism of persistence is quite simple and can be implemented in any real programming language. I have no idea why anyone makes a big deal about it. Maybe I only think that because of the fluidity of Perl's data structures - it's a no-brainer for us to create arbitrary "trees" of data, serialize and deserialize them.