Actually, I can think of good reasons to cache CSS keys: when one has their entire DVD collection copied to a home server.
Yes, you could rip the DVD and decrypt the content, and use clients to read it without ever worrying about CSS again. But, stop and think: what if someone broke into your house and stole that server? Or, cracked through your firewall and just sucked the content down? Now, they start redistributing copies of copyright content that you've conveniently decrypted for them. To what extent have you contributed to their crime of copyright infringement?
I'd say you were at least negligent in not properly protecting the copyright content of the copyright holder: you took some pains to remove what protection they applied, and then did not substitute something at least as good.
Yes, yes, with deCSS so easily available, it's not like the crook needed your help, but, and IANAL, I don't think that matters when determining your negligence.
Personally, I prefer to keep ripped content encrypted, and have the playback devices maintain a cache of keys as appropriate (or access a secure CSS cache server that authenticates it's clients).
I haven't implemented this fully, but it should not be terribly difficult: combine xine's notion of maintaining a local CSS key cache, with a hacked nbd to access virtual remote DVDs.
Sixty bucks for an ethernet crimper?! Are you out of your head? The difference between the five dollar crimper and the sixty dollar crimper is the built-in wire stripper.
Well, "you pays your money and you makes your choice". Yes, the $60 model included a wire stripper, could crimp 8P8C and 6P6C connectors. It also included a bunch of 8P8C and 6P6C plugs. It came with a nice plastic case, which included storage compartments for the plugs. So, I only have to grab one box and a spool of cable if I'm on the run to go somewhere and make a cable. Personally, the price for the extra stuff, and convenience was worth it to me. It's also a nice metal tool rather than the cheap plastic ones -- I've used those and hate them.
Where did you find cheap PoE switches? I see them for around $100 a port -- I'm almost thinking of going WiSIP and just hardwiring a couple of lifeline phones with PoE and a POTS lifeline for 911. (Yes, I plan for the WiSIP phones to be on an Asterisk dialplan which will allow 911 out the POTS line, but if Asterisk crashes, or the WiSIP battery dies I want at least one hardwired phone on each floor that can give me 911, but still be available for VoIP calls under normal circumstances (Otherwise my wife will be calling Canuckistan on the "wrong" phone). I guess I trust the UPS more than Asterisk.
They make "universal" metal enclosures (i.e. a box with cover that can even be locked) with plywood backing in 14" and 28" by 16" (wide) sizes, designed to mount between (or on, for retrofit, on-wall, installation) studs.
They also make "universal" patch panels that accept up to 12 snap in connectors (like you can get at Home Depot -- they're cheaper in contracter packs). These come in 8P8C, 6P6C, Cat5, Cat5e, Cat6, RF, line level audio, and blank varieties. Terminate the incoming lines to a connector on a patch panel. Then you patch from there to whereever (a satellite multiswitch, or RF amp, or router/firewall) as appropriate.
For POTS (telephone lines), you can use cheap BIX-66 blocks (which happen to be the same size as the universal ones): you don't need fancy patch panels for that if you get good with a punch-down tool. Hint: get a good one, like a Greenlee. Last time I checked, they were about US$45 at Home depot, and the extra blade was another $15: you'll want a 66 and a 110 blade.
Save $$$ and make your own patch cables: get a spool or Cat5e and a crimping tool -- I happen to like Greenlee, but that's just from personal experience and satisfaction. The crimping tool goes for around US$60 and comes in a kit with a bunch of 8P8C and 6P6C plugs.
I did this in the first house I wired, as a retrofit withe the enclosures mounted on-wall. I used two enclosures: one for RF stuff, and one for voice and data. this was for a five bedroom 3200 square foot house. Yeah, 2xCat5e and 2xRG6-U cable to each drop.
Don't forget to allow for incoming lines: like from the phone company, cable company, and/or satellite dish. Hint, wire TWO cables to the POTS and cable entrances: that way you can "return" a feed to legacy house wiring (all in parallel) from your head end to the point where it used to enter the house.
In the next house I wired, I actually got an on-wall SwingLine rack (Ebay is great!), and rack-mountable patch panels. This costs a bit more, but lets you mount rack-mounted equipment, like multiswitches, routers, etc. Do leave a "universal" mounting board (plywood) nearby where you can mount equipment that can't be mounted in a rack. Alternately, have a shelf for such equipment (though I prefer wall mounts wherever possible).
Why a device that displays the time doesn't have an NTP client and an ethernet port, I don't know.
Why a device that knows the time (like my satellite receiver) doesn't have a configurable NTP server and an ethernet port, I don't know.
What I do know is that I have to go around the house twice a year trying to explain "Daylight Saving Time" to microwaves, stoves, clock radios (well not all of them). Been doing it for years. You'd think they'dve done learned it by now. Sheesh. Stupid electronics, "Converge this!"
I was too far for "normal" DSL service piggybacked over a POTS line (something like 14 kft.), but there was one provider that was willing to provision DSL over a second dry pair from the CO and pass on the dry pair costs without markup. Worked great, though the $15/month for the dry pair made my DSL bill around $80 a month.
Sadly, I can't remember with certainty the provider I had used.... Internet America, I think.
Re:SR-52 [[SIGH]] I was an Engineer on that...
on
TI-84 Plus Released
·
· Score: 2, Interesting
Well, kudos on a GREAT calculator. That thing was built like a tank (not that I intentionally abused it), to have lasted all those years.... 2 + 3 * 6 = 20 (not 30, as most calculators of the day would have indicated). Ah, AOS! (Algebraic Operating System, IIRC).
While studying in my first year toward a Computer Science degree, I wrote a cross-compiler for a high-level language for it, in Pascal, running on a CDC 6600 mainframe (c. 1979): TIPCAL: Texas Instruments Programable CAlculator Language. It was rather like a cross between BASIC and FORTRAN and spat out programming keystrokes.
Ah, the memories: A vaguely remember something about an SR60 desktop, yes.
damn whippersnappers :-) I remember my SR-52
on
TI-84 Plus Released
·
· Score: 2, Informative
... yeah, that's right: the one with the card reader and 226 (IIRC) program steps. Got it right around 1975 or so.
It finally died last year (though I hadn't used it seriously in ages).
Re:Waiting for this Slashdot headline...
on
HDTV TiVo Now Shipping
·
· Score: 0, Flamebait
it is your damn laws. tell your government to get rid of the regulations that keep TIVO out.
Canada is too far down the fascist slippery slope for that to work. In Ontario, for example, you don't get title to a house, or a car: your "ownership" is registered in a government database. Guess what could happen if someone became a serious thorn in the government's side?
There are two big reasons for keeping American satellite television out of Canada:
1. Economically, the local satellite and cable providers don't want the competition. They lobby the government.
2. Politically, it's bad to have television showing an American freedom-loving lifestyle and prosperity in fascist Canada: some might get the idea that they should be able to enjoy a similar lifestyle if they work hard.
But, in Canada, the idea has been driven into the population that we are a "caring society that looks out for the weak and downtrodden". Woe to those that reveal the truth: anyone who manages to be better off via the sweat of their brow (i.e. hard work) is being unfair to those less well off, in particular those that don't care to work at all. These people make up a frighteningly large fraction of the voting population.
So, the mantra is, "anyone better off than me is unfair, and un-Canadian... they have to do their share to support me" This attitude is indoctrinated in the schools: the vast majority of people are not generally gifted intellectually, and so are encouraged to join the fascist status quo to make the minority that are work for them. As a result, taxes are extremely high (while federal marginal rates are comparable to those in the U.S., provincial rates are higher than state rates, there are almost no deductions, the equivalent of exemptions are turned into tax credits at the lowest marginal rates and not straight deductions from income, and, there is the dreaded GST (federal goods and services tax) of 7% on almost everything you buy (including resale cars and new homes), and provincial sales taxes that add another 8%, typically). A married couple with a single income earner can't file jointly, and mortgage interest is not deductable.
Health care is a joke: get sick and see how long you have to wait for mediocre care -- in Ontario you have to agree to live there permanently to be eligible at all. It is illegal to purchase private health care (except as an adjunct to provincial care, so you can't get treated faster or better, but can, perhaps, get a semi-private hospital room, instead of staying on the ward).
In practice this means that the extra taxes you pay for nationalized health care go to those welfare lardasses supported by the remainder of your taxes who have ballooned to 440 lbs. (200 kg.) eating McDonalds burgers and poutine (french fries with cheese curd, and gravy) and now need heart bypass surgery instead of paying for the ostheoarthritic surgery or aortic aneurysm repair that you require. You're so poor that you couldn't afford to purchase the surgery on the free market after all the taxes you paid (supposedly, in part, for this very care!).
It's a fascist hell.
But, the clock is ticking on the "tax slaves' revolution". Increasingly, the retired and elderly who worked all their lives and supported the system see that it is not available to them when they need it the most. As the population ages, they are becomming an increasingly signficicant political force and see that some 35 years of socialism has been a great fraud perpetuated on them. I hope to see the day when they, and mostly the tax slaves that have escaped to work elsewhere, return, a million strong, to Parliment Hill with rocket launchers, and fully-automaticaly modified AR-15s, to take back their country, from the corrupt government in power and anyone else standing in their way who robbed them.
It's not easy to work elsewhere, bidding one's time and saving one's money: when in the U.S., and losing my job in the telecom bust, I had to return, of course, l
Now all I have to do is find a quiet computer so it won't keep me up all night and I'll do all that!
...or simply put the home media server in an unobtrusive place, like the home office, or basement. When I lived in Allen, Texas, I had ours in the master bedroom closet (which, because the master bathroom was between it and the master bedroom, was far enough away that it didn't keep us up at night from the fan noise). Of course, if you do as I did, make sure you have a HVAC vent to that closet.
Or I can buy a computer, buy a wireless lan card, buy a wireless lan radio, configure everything, PAY for a reasonable intenet connection, listen, enjoy (within a small area around my hub)
Point noted.
But, you forget something: that computer, LAN card, (or hard-wired LAN), and internet connection has more uses than just serving as a home portal for "wireless internet radio". So, while the observation that the overhead of such a device is significant, one should really be amortizing it over all the useful functions it can perform:
1. Web, email, and news: that's a no-brainer. Most people use a computer for just that. Anything else, therefore, is gravy. Though, it is true, that if you're serious about having a home media portal, you'd probably want a dedicated machine, and not one used for interactive purposes. On the plus side, it does not have to be particularly powerful, or have a fancy graphics card, but should have mondo storage (a Terabyte is not ultimately unreasonable, though you can do a lot with 100 GB, if you don''t need to rip too many DVDs.). Whether a dedicated machine, or not, the internet connection is still "justified" by the desire to browse and have email connectivity.
2. Media storage. You can store local media on such a server: pictures, music, and videos.
3. Fax server. you can receive faxes with either an email to fax gateway, or directly with a cheap fax modem.
4. Application storage. A single repository for applications used in the home is handy.
5. Personal data storage. Hello...? "mount -t nfs server:/home/home". 'Nuff said.
6. Email server. (3) kinda makes this obvious, but I don't wanna make this first and renumber, so... If you have an "always on" connection, preferrably with a static IP, why not sink your own email, rather than POP or IMAP it from somewhere on a polling basis (except, of course, your backup MX). This does mean finding an ISP that's willing to let you open port 25 to the world, and like a good mail admin you don't act like an open relay, but, it's worth it.
7. Voice Mail server. If you've got the FAX modem, you might as well get one that does voice as well. Turn the home media server into an answering machine, transcode, and forward messages to the MTA.
8. Home automation control system.
9. Home alarm monitoring system.
10. VoiP gateway. A CISCO ATA-186 does wonders.
When you add up all the possible uses of a home media server/control computer, it actually becomes a bargain. The trick is tying all those functions together. There is a bit more overhead to worry about if you get serious: a UPS is almost essential, and backup device strongly reccomended (though you could opt for RAID or a reciprocal remote rsync arrangement with a trusted friend).
Well, StarTrek did begin with TV's most flagrant split infinitive. ("...to boldly go...")
Indeed.
It's "...to fucking go boldly..."
Er...
"...to go fucking boldly..."
Er...
"...to go boldly fucking..."
...fuck this language, "English" and the lack of written designations for metadata: "fucking" was supposed to be a metadata expletive about the splitting of an infinitive... instead it gets promoted to the rank of a bona-fide verb or adverb. Arrogant word, that: "fuck".
Indeed. I've worked with free, open source, and proprietary software, generally as an in-house user and small redistributer (when you employ free and open source software in supported aggregates that license for tens of millions of dollars, you have few large customers who generally do not redistribute -- this is an interesting double-edged sword: it's easy to comply with the GPL when your distribution is minor, but difficult to verify complience and the free code you contribute tends to stay within an extremely small user community).
I think there is a place for both free and non-free software in the marketplace, and the days of exploiting non-free code for vendor support "lock-in" are numbered. The public just has to realize the true costs of not having source. RMS would argue that it's a moral, and not economic issue, but I can not see that something that is morally good can be economically harmful.
1. Answer: nothing, if the software is not intended for use by anyone but its authors and the elite.
This is generally the case from the perspective of people who write software to solve a particular problem.
2. However, if we want "the rest of the world" to adopt and love an open source solution over an old proprietary one, then inaccessibility is bad.
True, but those doing the evangelizing are often not those doing the developing! Granted, there are some exceptions (Desktop development, the whole GNU effort), but high-profile evangelizing generally is divorced from development -- those ranting the most are often those developing the least and presume to suggest what developers should do. One can "suggest" all they want, but unless they have an agreement with a developer, that's all they have a moral right to do.
3. Resisting efforts to legally erradicate open source software requires popularity. If our numbers are small enough, our rights can be taken away.
Well, not according to the U.S. Constitution (if you happen to live in the U.S.A.), even as it's being Patriot Acted to death. But the point is a good one. Still, a small movement tends to be not worth the while to attack, and a large one is beyond legislative attack. The vulnerability occurs at the midpoint, just when something is starting to "take off".
I think the open source movement has advanced beyond that stage -- it offers enough cost savings to cost-sensitive organizations to be "kept legal". IBM isn't in this for the philosophical aspects, you know.
The greatest danger, though, is in an attack on the free software movement. By driving a wedge between open source and free software, one can vilify one as extreme, while grudgingly tolerating the other. I can imagine laws passed that permit certain combinations of open and closed code that the GPL might arguably forbid, under pressure from industry to "mine" GPL-licensed software to "reduce costs", and stave off "layoffs". Yes, this would likely be illegal in the context of present copyright law, but who says the law is internally consistent?
It is espescially dangerous when people are quite willing to use non-free applications on free operating systems, or vice-versa; or when the notion that a closed kernel module might not be acceptable to a future kernel license causes concern to those who want to use it.
Personally, I think these kinds of combinations of free and non-free software are acceptable -- the GPL draws quite a useful line, as unclear as it may be when it comes to the notion of plugins and non-free dynamically linked extentions to free code (and vice-versa). In any case, people will want to make them for reasons of sheer convenience. Nevertheless, the right of people to use the GPL, or an even more stricter free software licence, if they choose, should not be infringed.
But, I am not convinced that making open source software popular will help in this area -- it's a philosophical and moral debate, and not a pragmatic one: open source will always be more convenient that completely free software (particularly that with a license stricter than the GPL 2.0 -- GPL 3.0, perhaps?) simply because it admits a coexistance with non-free software, albeit perhaps subject to GPL restrictions. Just look at the popularity of Debian vs. Red Hat vs. Suse distributions. Debian, true to the free software philosophy is the dark horse, and I'm not entirely convinced that it is due to UI ease of use issues.
So, while I don't think that open source software is going away any time soon, I do think that free software might come under the legislative attack you descrbe, and the force to counter it would be philosophical argument not popularity, since few would understand the difference between the two. While popular open source software can help the free software movement (and I think open source is popular enought to survive legislative attack), I don't think it will be enough to protect it unless
the philosophical differences between the two are understood.
To quote the article: The result is that Open Source projects are made by programmers for programmers, who then can?t understand why the general public would bother with proprietary software when this Open Source tool is working so well for them. Meanwhile, the rest of the world begins to associate "Open Source" with software that?s only accessible to the technocratic elite.
I say, "What's wrong with that?"
Is there some inviolate law that says people have to program for others for free (as in "with no charge")? I hear Marx muttering from his grave, "...from the programmer to the end user...".
If you don't like what you get without charge, then either expend the effort to change it, or pay someone to do it for you. I don't expect doctors to treat me for free, or lawyers to represent me for free, so why is there this perception that those that provide software without charge should somehow be obliged to meet some arbitrary whim?
Granted, ease of use translates into popularity translates into greater support, and those that care about software popularity might make the effort to consider usability issues. Hint: that may not be the prime developer of a particular piece of software.
Linux was not created for your benefit or mine: it was created by Linus Torvalds for himself. Of course, others with similar interests shared and contributed to that effort, and the synergy is amazing. But the fact that it is useful to you or I is happy coincidence.
Elitist, indeed. And ultimately self destructive.
You know, I have a brother in law that is seriously into motorcycles. He goes on and on about minutae of bikes that I barely understand. Elitist? Perhaps. But, he does not require or expect me to share his interest or desires. And, I do not expect him to explain things to "my level". Why is it, then, that we expect open source and free software programmers to "owe" something to society? Ironic how free software, wrongly criticized for being "communist" suffers under accusers far more "red" than it's protagonists.
"Ultimately self destructive?" I suppose if a popularity contest or some measure of market share is the issue, the argument might hold a drop of water. But, that isn't the issue, and never was. If free software requires popularity, it is only because opponents of the philosophy behind it would seek to use the force of corporatist-purchased government law and force to extinguish it's fire. Frankly, with IBM and others "on side", I don't think we need to worry about that.
I am not a free software or open source zealot. I believe that the only way to produce mass-market user-interacting software is with the kind of market research that can only be funded by providers of proprietary software. That said, there are large underlying components of such software that could be leveraged in other areas and will soon be supplanted by free alternatives, commoditizing them at zero cost to end users. The line has been drawn between effective free operating systems and non-free applications and services. The question is how much will it move into the application space? My bet: "Not very much."
Free office suites and web browsers will exist, of course, but will generally play the "compatibilty catch up game" with their most popular non-free counterparts. They will be standards-complient and Microsoft-incompatible. Maddeningly, standard non-conforming software will continue it's popular ride. The market, after all, is not made up of a majority that can evaluate the benefits of the free vs. non-free alternatives: they get their decision-making input from TV. I've yet to see a television ad for Apache (notwithstanding in the context of IBM hardware and support).
I mean you could consider every single program on Linux to be a "plugin for Linux" and thus they should all be in the one "Linux directory".
Yes, of course. And this is not unreasonable. But the problem then becomes one of keeping the individual applications from interfering with each other. Either Linux specifies an installation standard, or the end-user is required to make sure that things don't collide -- we're all familiar with applications that rely on a variety of directories which the end-user has to specify.
This is where standards like the FHS help: they provide a reccomendation of where application components should be installed, or at least where one particular hierarchy describes their component parts. Still, FHS is not the be-all-and-end-all for all application requirements.
5. An "init" file that is text-editable. But by default it looks in ~/.app/ for the plugins as well as the plugins subdirectory. It will also source identical files in the ~/.app directory. So if you have your own plugins, you can add them by putting them in your home directory, by modifying the init in your home to point where they are installed, or (with permission) by editing the original.init file.
This breaks the "single directory" model because now the application has to look under your home directory, or some place other than it's "main" directory, for plugins. It's either that or you have to accept that the application's "main" directory is writable in order to change the plugins available to it -- not too good an idea.
FHS tries to counter this with a limited number of directories for third party software - read only installation, read/write configuration/localization, etc. But, it does mean that software B that provides pliguns for sofrware A installs in A's "turf", as it were, and we're back to installing all over the place. Package managers help to the degree that they track where "all over the place" is, for a given package. But, this strikes me as not sufficient to elegantly address the problem.
I suppose the best you can do is try to minimize the difficulty in installing/uninstalling your application, but that does nothing for the end user with regard to other, less-well behaved applications.
The FHS (File System Standard) is an attempt to provide a standard way of organizing the various parts of components, and limits the number of directories that need to be managed for each third party application.
It's a good start -- I've used it as the "official" organizational standard when building an internal custom GNU/Linux distribution.
But, it still enforces a particular hierarchy, generally to keep the traditional operating system components playing nice as new applications are added. There is no guarantee that it will be the most appropriate hierarchical organization in all cases: what about multiple versions of different applications that one wants to install simultaneously and their interdependencies? What about forked applications with different version number namespaces?
While the FHS is good, and useful, it is but one hierarchy. To impose it is not good geek style, though neither is it wise to reinvent a perfectly good wheel. What we really need is a way to organize the files that make up applications in multiple hierarchies, as appropriate, letting each application also define an application-specific hierarchy as appropriate for it's novel organizational needs. This does not, of course, mean that application must define their own hierarchies -- emphasis should be on using existing, perfectly functional ones (not the least of which is the OS core, generally represented by something like the FHS) where possible. Leverage and reuse is the name of the game here.
The issue really becomes one of managing all the different file hierarchies, and the effect that a file change or removal has on all the hierarchies in which it participates. Package management addresses these issues in the package management space, or hierarchy, as it were, but I find that it does so as a layer above the filesystem, requiring an all or nothing approach to reap the benefits. Furthermore, as application packages all installed "above" a core operating system, it strikes me that the core operating system should provide some facilities to simplify applicaiton interaction.
I'm not sure that this means moving package management into the O/S and adding a layer of insulation above the filesystem. Instead, files in the filesystem should have attributes reflecting the various hierarchies or views as the parent responder suggests, in which the file participates: the file and directory hierarchy is but one such view, after all, and this view remains a useful one.
I keep thinking that "callbacks" to application managers that can be registered on individual file changes within the filesystem remain the appropriate architectural model on which to build. Note that I would not necessarily think that individual applications be permitted to directly manage common "hot" files, like configuration files under/etc: the formats differ (though an XML-ized/etc can help here, bootstrapping it is a hassle). Instead, the O/S provides a set of interfaces to manage the configurable aspects it offers:/etc/services, for example, does is not generally edited by packages installers and deinstallers, but rather, an O/S facility is provided to manage changes to it, and other such configuration files: applications, after all, should know the configuraion changes they wish to make to other applications or the operating system.
This reduces the filesystem callback requirements to ones of create, move, or remove alone, and not change. That should simplify things.
Like so many package management models, this one has benefits (simplicity, package isolation, multiple package version coresidence) and drawbacks, the biggest one being package isolation, also an obvious benefit.
The trouble stems if you have some kind of base package, which is extensible via some kind of plug-in architecture, traditionally implemented with DLLs under Windows, or shared object library repositories under Unix and varients. Do the plugins form their own "application" or are they part of the application which they extend? What if I want to manage groups of plugins from a common source, independent of the applications extended? Do all applications have to be so isolated that they can only rely on a common base operating system that can't be extended by third parties (which would then be locked into their own application spaces)? What about multiple users sharing the same applications: will their saved files be intermingled?
Blech. Sounds like the cure is worse than the disease.
But, nevertheless, the idea of organizing independent applications in a convenient hierarchy is a desirable one. The trouble is that the traditional filesystem only offers a single hierarchy in which to organize them and so we struggle to determine the best hierarchy to use. We really need to organize sets of files that compromise a related unit ("file set", if you will, and "application file set", for the specific case of end-user applications) in multiple hierarchies: a new one created for the file set being added, and existing ones that the file set affects.
"Symlinks!"
What's that?
"Symlinks!"
Well, O.K. symlinks kind of solve this problem: pick a cannonical location in the file system for your file set and symlink secondary links to the appropriate files. This is a good idea, and has been used for ages to separate the reference to a file in the filesystem from where it is actually stored, but there are drawbacks:
1. Symlinks are one-way. Typically you'll have an application directory full of files and subdirectories, and a bunch of links into that directory tree. What happens if you move or delete entries? Oh, woe to the who has broken symlinks.
2. The context in which the symlink is interpreted may restrict where the target may be. Consider startup scripts added under/etc/rc.d/... They' don't do much good if they link to files in filesystems that haven't yet been mounted. Some restriction to where things have to be canonically installed depending on how and when they will be used is apparent. Fortunately, we generally don't have complicated hierarchies of what parts of the filesystem are mounted, but rather just a few: boot, locally mounted, remotely mounted. So, this problem is managable: we can inagine/opt and/usr/opt: the former available on the root filesystem.
3. Application interaction. The trouble with having one application extend the capabilities of another (and the base O/S can be considered as "one application" from the perspective of third party software providers, other than the O/S provider) is that adding, moving, or removing files can or should affect running applications. Ideally, an action which would leave a symlink dangling should be picked up by any running applications that might care and either delayed until the application can cope, or vetoed. (And, I suppose, --force and --async are your friends here).
Current practice in most package managers is to have pre-install, post-install, pre-deinstall, and post-deinstall scripts that try to deal with this inter-application issue. The problem is two fold: (1) the things necessary to be communicated to other applications are varied, and (2) the manner in which they are communicated differ between applications (never mind different versions of the same application). Ideally, the inter-application interface that deals with new, removed, or relocated external files should be (a) thin, and (b) supported by t
Social evolution in action: corporations are more efficient -- better adapted to their environment -- than nation-states.
About corporate power? We can do nothing.
Gee, how defeatist.
Consider, when the product is software, cooperatives have demonstrated that they can give the supposedly efficient mega corporation a damn good run for it's money.
I'm talking, of course, about Tux vs. Microsoft. Microsoft has admitted that Linux is it's biggest threat.
Now, I don't think that Microsoft is going to disappear any time soon, but I do think that the desire for a free operating system had a lot to do with the collaborative effort that made Linux a reality, heck, Windows didn't satisfy Torvalds' view of what an operating system should be and he started to scratch that itch.
"But," I hear the gentle reader protest, "you can't make money writing and giving software away for free."
Perhaps not, but that isn't the point -- I don't rake my yard to make money. I don't organize my house just so to make money. I do these things to make my life easier -- the effort I expend is justified by the benefits I reap. And so it is with free software -- individual investments in tool-building compounded by collaborative network effects "on steroids". We do it to save money, or reduce expenses, in the sense of making our lives easier, rather than increase revenue. Last time I checked, income=revenue-expenses. You don't have to increase revenue to increase income. Inflation causes both revenue and expenses to increase over time, so there is effectively no limit to expense reduction, save time.
The funny thing is that I make my living writing non-free software licensed for millions of dollars to a handful of organizations, and that most people wouldn't even want to be free, as they'd derive no use of it (well, some might be handy to be free to a small minority, and it is a bit of an ethical dilema to keep it non-free, but hey, the market isn't perfectly efficient all the time). Bottom line is that Microsoft isn't going to go away any time soon -- In fact I'd bet on it being around for a while, strengthened by eventually getting out of the areas where Linux shines, though I do think the days that Windows being the vehicle that gives Windows apps a lock on the market are numbered. Buy time, and leverage strength, Bill. I'd go so far as to argue that there wouldn't be Linux, if Windows didn't exist. Necessity, Invention, Mothers. You add them up.
So, the uber-powerful corporation will be reduced, over time, to that which it can continue to do most efficiently or learn to do most efficiently where it hasn't done it before.
The difficulty some face is that they might find the natural time table for this "correction" not to their liking, wishing to use the strong hand of the state to restore "fairness" faster. Funny how wishing for strong governments doesn't always get you what you want, isn't it?
When I first saw LeGuinn's name mentioned in this article, I thought of The Lathe of Heaven. I rented it on DVD (yes, despite feeding the bastards, I do occasionally rent a movie -- I try keeping consumption down though -- better to support the brewing industry than the MPAA) a while back, and liked it very much.
YMMV.
Don't think I would buy the DVD, but it was worth the $5.00 rental, IMHO.
1. They're "all in one" devices": jacks of all trades, and masters of none.
2, They're "stylish", whatever that means.
So, the question really becomes, "Are there times and places when and where a low powered, good looking computer is appropriate?". The answer, is a resounding, "YES!"
Look no further than the trials and tribulations of those trying to put together an HTPC (Home Theater Personal Computer): Oh the agony of the fan noise, the ugliness of the case, and so on. It doesn't take much to play music, and playing video from common digital sources only takes a bit more "oomph" (actually, very little more, if you have hardware-assisted MPEG2 decoding). Rendering web-pages is child's play, if you can decode MPEG2 video. What else is there that a computer-as-entertainment device needs to do? About the only thing you can't do with a "low power" computer is play the latest uber-game, for lack of video horsepower. Still, one can achive a wonderful level of entertainment convergence even without this capability.
I have a nice, mid-1980s Bang & Olufsen Beosystem 5500 stereo system: receiver, turntable, CD player, and cassette deck. It drives external Carver amps, Bohlender-Graebner Radio 5000 speakers, and a custom-built amplified subwoofer. It rocks, and looks fscking cool! Yes, it cost 2-3 times as much as a system that sounds as good, but a system that sounds noticibly better would cost 10 times as much -- at some point you stop paying for performance and start paying for style, particularly if you want a nice family room. It complements a Sony HD-ready television, HD satellite receiver, and DVD player. Hmm, the "style" starts to suffer from all the stuff interconnected. But, it get's worse.
See, the B&0 CD player and the DVD player take single disks. Oh sure, I could get a CD/DVD jukebox, but they're, well, ugly (I payed for good looks, remember?). Besides, such things didn't exist in 1987, not even for CDs, when I got the stereo. So, I have a custom-built solid oak-and-granite-and-fancy-suspension-system cabinet to "show off" the B&O equipment and house up to 240 CDs, 90 cassettes, and have a shelf for "misc.", er, DVDs, yeah, I anticipated those cases, that's it. It looks great! Ain't I smart (if obnoxious, at this point?).
Well, perhaps, but not really. Like I said, interconnecting all that equipment detracts from the elegance -- it should "look simple". B&O gets this part right. The cabinet is utterly useless for CD number 241 or cassette number 91 (dunno how many DVD cases it can hold). Now, what would be really slick would be nothing other than a single box, connected to TV or alternate display, and external audio amps and speakers, or multichannel receiver.
Gee, sounds like a lifestyle computer, no?
Granted, the "lifestyle" systems currently available, while stylish, aren't really designed for this kind of use. But, the A/V convergence is encouraging. We're starting to see smarter and smarter set top boxes and networked DVD players. Between OTA and satellite television, there aren't that many different standards that need be accomodated (legacy analog, ATSC, and DVB). A one-size-fits-all tuner box, capable of retrieving digital content over the air, via satellite, or LAN (with WAN gateway to the Internet), isn't that much of a stretch any more. Include a DVD/CD drive, and you're done. Heck, there are digital video processors like ATI's Xilleon varients that already do all manner of ATSC, MPEG, with analog output encoding for NTSC, PAL, and SECAM, with a 300 Mhz MIPS processor to boot.
We're not there yet: current offerings are either ugly or awkward to use, or both. Still, that such first generation convergence devices exist at all, together with stylish lifestyle computers suggests that an eventual optimal merger between the two ideas might happen hopefully sooner than later.
Anyone wanna buy a nice hardwood and granite stereo cabinet?
Slashdot Mirror
Actually, I liked the parody: perhaps one of the few forms of fair use left undisturbed.
Yes, you could rip the DVD and decrypt the content, and use clients to read it without ever worrying about CSS again. But, stop and think: what if someone broke into your house and stole that server? Or, cracked through your firewall and just sucked the content down? Now, they start redistributing copies of copyright content that you've conveniently decrypted for them. To what extent have you contributed to their crime of copyright infringement?
I'd say you were at least negligent in not properly protecting the copyright content of the copyright holder: you took some pains to remove what protection they applied, and then did not substitute something at least as good.
Yes, yes, with deCSS so easily available, it's not like the crook needed your help, but, and IANAL, I don't think that matters when determining your negligence.
Personally, I prefer to keep ripped content encrypted, and have the playback devices maintain a cache of keys as appropriate (or access a secure CSS cache server that authenticates it's clients).
I haven't implemented this fully, but it should not be terribly difficult: combine xine's notion of maintaining a local CSS key cache, with a hacked nbd to access virtual remote DVDs.
Well, "you pays your money and you makes your choice". Yes, the $60 model included a wire stripper, could crimp 8P8C and 6P6C connectors. It also included a bunch of 8P8C and 6P6C plugs. It came with a nice plastic case, which included storage compartments for the plugs. So, I only have to grab one box and a spool of cable if I'm on the run to go somewhere and make a cable. Personally, the price for the extra stuff, and convenience was worth it to me. It's also a nice metal tool rather than the cheap plastic ones -- I've used those and hate them.
Where did you find cheap PoE switches? I see them for around $100 a port -- I'm almost thinking of going WiSIP and just hardwiring a couple of lifeline phones with PoE and a POTS lifeline for 911. (Yes, I plan for the WiSIP phones to be on an Asterisk dialplan which will allow 911 out the POTS line, but if Asterisk crashes, or the WiSIP battery dies I want at least one hardwired phone on each floor that can give me 911, but still be available for VoIP calls under normal circumstances (Otherwise my wife will be calling Canuckistan on the "wrong" phone). I guess I trust the UPS more than Asterisk.
They also make "universal" patch panels that accept up to 12 snap in connectors (like you can get at Home Depot -- they're cheaper in contracter packs). These come in 8P8C, 6P6C, Cat5, Cat5e, Cat6, RF, line level audio, and blank varieties. Terminate the incoming lines to a connector on a patch panel. Then you patch from there to whereever (a satellite multiswitch, or RF amp, or router/firewall) as appropriate.
For POTS (telephone lines), you can use cheap BIX-66 blocks (which happen to be the same size as the universal ones): you don't need fancy patch panels for that if you get good with a punch-down tool. Hint: get a good one, like a Greenlee. Last time I checked, they were about US$45 at Home depot, and the extra blade was another $15: you'll want a 66 and a 110 blade.
Save $$$ and make your own patch cables: get a spool or Cat5e and a crimping tool -- I happen to like Greenlee, but that's just from personal experience and satisfaction. The crimping tool goes for around US$60 and comes in a kit with a bunch of 8P8C and 6P6C plugs.
I did this in the first house I wired, as a retrofit withe the enclosures mounted on-wall. I used two enclosures: one for RF stuff, and one for voice and data. this was for a five bedroom 3200 square foot house. Yeah, 2xCat5e and 2xRG6-U cable to each drop.
Don't forget to allow for incoming lines: like from the phone company, cable company, and/or satellite dish. Hint, wire TWO cables to the POTS and cable entrances: that way you can "return" a feed to legacy house wiring (all in parallel) from your head end to the point where it used to enter the house.
In the next house I wired, I actually got an on-wall SwingLine rack (Ebay is great!), and rack-mountable patch panels. This costs a bit more, but lets you mount rack-mounted equipment, like multiswitches, routers, etc. Do leave a "universal" mounting board (plywood) nearby where you can mount equipment that can't be mounted in a rack. Alternately, have a shelf for such equipment (though I prefer wall mounts wherever possible).
Why a device that knows the time (like my satellite receiver) doesn't have a configurable NTP server and an ethernet port, I don't know.
What I do know is that I have to go around the house twice a year trying to explain "Daylight Saving Time" to microwaves, stoves, clock radios (well not all of them). Been doing it for years. You'd think they'dve done learned it by now. Sheesh. Stupid electronics, "Converge this!"
I was too far for "normal" DSL service piggybacked over a POTS line (something like 14 kft.), but there was one provider that was willing to provision DSL over a second dry pair from the CO and pass on the dry pair costs without markup. Worked great, though the $15/month for the dry pair made my DSL bill around $80 a month.
Sadly, I can't remember with certainty the provider I had used.... Internet America, I think.
While studying in my first year toward a Computer Science degree, I wrote a cross-compiler for a high-level language for it, in Pascal, running on a CDC 6600 mainframe (c. 1979): TIPCAL: Texas Instruments Programable CAlculator Language. It was rather like a cross between BASIC and FORTRAN and spat out programming keystrokes.
Ah, the memories: A vaguely remember something about an SR60 desktop, yes.
It finally died last year (though I hadn't used it seriously in ages).
Canada is too far down the fascist slippery slope for that to work. In Ontario, for example, you don't get title to a house, or a car: your "ownership" is registered in a government database. Guess what could happen if someone became a serious thorn in the government's side?
There are two big reasons for keeping American satellite television out of Canada:
1. Economically, the local satellite and cable providers don't want the competition. They lobby the government.
2. Politically, it's bad to have television showing an American freedom-loving lifestyle and prosperity in fascist Canada: some might get the idea that they should be able to enjoy a similar lifestyle if they work hard.
But, in Canada, the idea has been driven into the population that we are a "caring society that looks out for the weak and downtrodden". Woe to those that reveal the truth: anyone who manages to be better off via the sweat of their brow (i.e. hard work) is being unfair to those less well off, in particular those that don't care to work at all. These people make up a frighteningly large fraction of the voting population.
So, the mantra is, "anyone better off than me is unfair, and un-Canadian... they have to do their share to support me" This attitude is indoctrinated in the schools: the vast majority of people are not generally gifted intellectually, and so are encouraged to join the fascist status quo to make the minority that are work for them. As a result, taxes are extremely high (while federal marginal rates are comparable to those in the U.S., provincial rates are higher than state rates, there are almost no deductions, the equivalent of exemptions are turned into tax credits at the lowest marginal rates and not straight deductions from income, and, there is the dreaded GST (federal goods and services tax) of 7% on almost everything you buy (including resale cars and new homes), and provincial sales taxes that add another 8%, typically). A married couple with a single income earner can't file jointly, and mortgage interest is not deductable.
Health care is a joke: get sick and see how long you have to wait for mediocre care -- in Ontario you have to agree to live there permanently to be eligible at all. It is illegal to purchase private health care (except as an adjunct to provincial care, so you can't get treated faster or better, but can, perhaps, get a semi-private hospital room, instead of staying on the ward).
In practice this means that the extra taxes you pay for nationalized health care go to those welfare lardasses supported by the remainder of your taxes who have ballooned to 440 lbs. (200 kg.) eating McDonalds burgers and poutine (french fries with cheese curd, and gravy) and now need heart bypass surgery instead of paying for the ostheoarthritic surgery or aortic aneurysm repair that you require. You're so poor that you couldn't afford to purchase the surgery on the free market after all the taxes you paid (supposedly, in part, for this very care!).
It's a fascist hell.
But, the clock is ticking on the "tax slaves' revolution". Increasingly, the retired and elderly who worked all their lives and supported the system see that it is not available to them when they need it the most. As the population ages, they are becomming an increasingly signficicant political force and see that some 35 years of socialism has been a great fraud perpetuated on them. I hope to see the day when they, and mostly the tax slaves that have escaped to work elsewhere, return, a million strong, to Parliment Hill with rocket launchers, and fully-automaticaly modified AR-15s, to take back their country, from the corrupt government in power and anyone else standing in their way who robbed them.
It's not easy to work elsewhere, bidding one's time and saving one's money: when in the U.S., and losing my job in the telecom bust, I had to return, of course, l
Or I can buy a computer, buy a wireless lan card, buy a wireless lan radio, configure everything, PAY for a reasonable intenet connection, listen, enjoy (within a small area around my hub)
Point noted.
But, you forget something: that computer, LAN card, (or hard-wired LAN), and internet connection has more uses than just serving as a home portal for "wireless internet radio". So, while the observation that the overhead of such a device is significant, one should really be amortizing it over all the useful functions it can perform:
1. Web, email, and news: that's a no-brainer. Most people use a computer for just that. Anything else, therefore, is gravy. Though, it is true, that if you're serious about having a home media portal, you'd probably want a dedicated machine, and not one used for interactive purposes. On the plus side, it does not have to be particularly powerful, or have a fancy graphics card, but should have mondo storage (a Terabyte is not ultimately unreasonable, though you can do a lot with 100 GB, if you don''t need to rip too many DVDs.). Whether a dedicated machine, or not, the internet connection is still "justified" by the desire to browse and have email connectivity.
2. Media storage. You can store local media on such a server: pictures, music, and videos.
3. Fax server. you can receive faxes with either an email to fax gateway, or directly with a cheap fax modem.
4. Application storage. A single repository for applications used in the home is handy.
5. Personal data storage. Hello...? "mount -t nfs server:/home /home". 'Nuff said.
6. Email server. (3) kinda makes this obvious, but I don't wanna make this first and renumber, so... If you have an "always on" connection, preferrably with a static IP, why not sink your own email, rather than POP or IMAP it from somewhere on a polling basis (except, of course, your backup MX). This does mean finding an ISP that's willing to let you open port 25 to the world, and like a good mail admin you don't act like an open relay, but, it's worth it.
7. Voice Mail server. If you've got the FAX modem, you might as well get one that does voice as well. Turn the home media server into an answering machine, transcode, and forward messages to the MTA.
8. Home automation control system.
9. Home alarm monitoring system.
10. VoiP gateway. A CISCO ATA-186 does wonders.
When you add up all the possible uses of a home media server/control computer, it actually becomes a bargain. The trick is tying all those functions together. There is a bit more overhead to worry about if you get serious: a UPS is almost essential, and backup device strongly reccomended (though you could opt for RAID or a reciprocal remote rsync arrangement with a trusted friend).
Indeed.
It's "...to fucking go boldly..."
Er...
"...to go fucking boldly..."
Er...
"...to go boldly fucking..."
not the overkill of Subversion, and a bit dated, but it'll do.
I think there is a place for both free and non-free software in the marketplace, and the days of exploiting non-free code for vendor support "lock-in" are numbered. The public just has to realize the true costs of not having source. RMS would argue that it's a moral, and not economic issue, but I can not see that something that is morally good can be economically harmful.
1. Answer: nothing, if the software is not intended for use by anyone but its authors and the elite.
This is generally the case from the perspective of people who write software to solve a particular problem.
2. However, if we want "the rest of the world" to adopt and love an open source solution over an old proprietary one, then inaccessibility is bad.
True, but those doing the evangelizing are often not those doing the developing! Granted, there are some exceptions (Desktop development, the whole GNU effort), but high-profile evangelizing generally is divorced from development -- those ranting the most are often those developing the least and presume to suggest what developers should do. One can "suggest" all they want, but unless they have an agreement with a developer, that's all they have a moral right to do.
3. Resisting efforts to legally erradicate open source software requires popularity. If our numbers are small enough, our rights can be taken away.
Well, not according to the U.S. Constitution (if you happen to live in the U.S.A.), even as it's being Patriot Acted to death. But the point is a good one. Still, a small movement tends to be not worth the while to attack, and a large one is beyond legislative attack. The vulnerability occurs at the midpoint, just when something is starting to "take off".
I think the open source movement has advanced beyond that stage -- it offers enough cost savings to cost-sensitive organizations to be "kept legal". IBM isn't in this for the philosophical aspects, you know.
The greatest danger, though, is in an attack on the free software movement. By driving a wedge between open source and free software, one can vilify one as extreme, while grudgingly tolerating the other. I can imagine laws passed that permit certain combinations of open and closed code that the GPL might arguably forbid, under pressure from industry to "mine" GPL-licensed software to "reduce costs", and stave off "layoffs". Yes, this would likely be illegal in the context of present copyright law, but who says the law is internally consistent?
It is espescially dangerous when people are quite willing to use non-free applications on free operating systems, or vice-versa; or when the notion that a closed kernel module might not be acceptable to a future kernel license causes concern to those who want to use it.
Personally, I think these kinds of combinations of free and non-free software are acceptable -- the GPL draws quite a useful line, as unclear as it may be when it comes to the notion of plugins and non-free dynamically linked extentions to free code (and vice-versa). In any case, people will want to make them for reasons of sheer convenience. Nevertheless, the right of people to use the GPL, or an even more stricter free software licence, if they choose, should not be infringed.
But, I am not convinced that making open source software popular will help in this area -- it's a philosophical and moral debate, and not a pragmatic one: open source will always be more convenient that completely free software (particularly that with a license stricter than the GPL 2.0 -- GPL 3.0, perhaps?) simply because it admits a coexistance with non-free software, albeit perhaps subject to GPL restrictions. Just look at the popularity of Debian vs. Red Hat vs. Suse distributions. Debian, true to the free software philosophy is the dark horse, and I'm not entirely convinced that it is due to UI ease of use issues.
So, while I don't think that open source software is going away any time soon, I do think that free software might come under the legislative attack you descrbe, and the force to counter it would be philosophical argument not popularity, since few would understand the difference between the two. While popular open source software can help the free software movement (and I think open source is popular enought to survive legislative attack), I don't think it will be enough to protect it unless the philosophical differences between the two are understood.
I say, "What's wrong with that?"
Is there some inviolate law that says people have to program for others for free (as in "with no charge")? I hear Marx muttering from his grave, "...from the programmer to the end user...".
If you don't like what you get without charge, then either expend the effort to change it, or pay someone to do it for you. I don't expect doctors to treat me for free, or lawyers to represent me for free, so why is there this perception that those that provide software without charge should somehow be obliged to meet some arbitrary whim?
Granted, ease of use translates into popularity translates into greater support, and those that care about software popularity might make the effort to consider usability issues. Hint: that may not be the prime developer of a particular piece of software.
Linux was not created for your benefit or mine: it was created by Linus Torvalds for himself. Of course, others with similar interests shared and contributed to that effort, and the synergy is amazing. But the fact that it is useful to you or I is happy coincidence.
Elitist, indeed. And ultimately self destructive.
You know, I have a brother in law that is seriously into motorcycles. He goes on and on about minutae of bikes that I barely understand. Elitist? Perhaps. But, he does not require or expect me to share his interest or desires. And, I do not expect him to explain things to "my level". Why is it, then, that we expect open source and free software programmers to "owe" something to society? Ironic how free software, wrongly criticized for being "communist" suffers under accusers far more "red" than it's protagonists.
"Ultimately self destructive?" I suppose if a popularity contest or some measure of market share is the issue, the argument might hold a drop of water. But, that isn't the issue, and never was. If free software requires popularity, it is only because opponents of the philosophy behind it would seek to use the force of corporatist-purchased government law and force to extinguish it's fire. Frankly, with IBM and others "on side", I don't think we need to worry about that.
I am not a free software or open source zealot. I believe that the only way to produce mass-market user-interacting software is with the kind of market research that can only be funded by providers of proprietary software. That said, there are large underlying components of such software that could be leveraged in other areas and will soon be supplanted by free alternatives, commoditizing them at zero cost to end users. The line has been drawn between effective free operating systems and non-free applications and services. The question is how much will it move into the application space? My bet: "Not very much."
Free office suites and web browsers will exist, of course, but will generally play the "compatibilty catch up game" with their most popular non-free counterparts. They will be standards-complient and Microsoft-incompatible. Maddeningly, standard non-conforming software will continue it's popular ride. The market, after all, is not made up of a majority that can evaluate the benefits of the free vs. non-free alternatives: they get their decision-making input from TV. I've yet to see a television ad for Apache (notwithstanding in the context of IBM hardware and support).
Yes, of course. And this is not unreasonable. But the problem then becomes one of keeping the individual applications from interfering with each other. Either Linux specifies an installation standard, or the end-user is required to make sure that things don't collide -- we're all familiar with applications that rely on a variety of directories which the end-user has to specify.
This is where standards like the FHS help: they provide a reccomendation of where application components should be installed, or at least where one particular hierarchy describes their component parts. Still, FHS is not the be-all-and-end-all for all application requirements.
5. An "init" file that is text-editable. But by default it looks in ~/.app/ for the plugins as well as the plugins subdirectory. It will also source identical files in the ~/.app directory. So if you have your own plugins, you can add them by putting them in your home directory, by modifying the init in your home to point where they are installed, or (with permission) by editing the original .init file.
This breaks the "single directory" model because now the application has to look under your home directory, or some place other than it's "main" directory, for plugins. It's either that or you have to accept that the application's "main" directory is writable in order to change the plugins available to it -- not too good an idea.
FHS tries to counter this with a limited number of directories for third party software - read only installation, read/write configuration/localization, etc. But, it does mean that software B that provides pliguns for sofrware A installs in A's "turf", as it were, and we're back to installing all over the place. Package managers help to the degree that they track where "all over the place" is, for a given package. But, this strikes me as not sufficient to elegantly address the problem.
I suppose the best you can do is try to minimize the difficulty in installing/uninstalling your application, but that does nothing for the end user with regard to other, less-well behaved applications.
It's a good start -- I've used it as the "official" organizational standard when building an internal custom GNU/Linux distribution.
But, it still enforces a particular hierarchy, generally to keep the traditional operating system components playing nice as new applications are added. There is no guarantee that it will be the most appropriate hierarchical organization in all cases: what about multiple versions of different applications that one wants to install simultaneously and their interdependencies? What about forked applications with different version number namespaces?
While the FHS is good, and useful, it is but one hierarchy. To impose it is not good geek style, though neither is it wise to reinvent a perfectly good wheel. What we really need is a way to organize the files that make up applications in multiple hierarchies, as appropriate, letting each application also define an application-specific hierarchy as appropriate for it's novel organizational needs. This does not, of course, mean that application must define their own hierarchies -- emphasis should be on using existing, perfectly functional ones (not the least of which is the OS core, generally represented by something like the FHS) where possible. Leverage and reuse is the name of the game here.
The issue really becomes one of managing all the different file hierarchies, and the effect that a file change or removal has on all the hierarchies in which it participates. Package management addresses these issues in the package management space, or hierarchy, as it were, but I find that it does so as a layer above the filesystem, requiring an all or nothing approach to reap the benefits. Furthermore, as application packages all installed "above" a core operating system, it strikes me that the core operating system should provide some facilities to simplify applicaiton interaction.
I'm not sure that this means moving package management into the O/S and adding a layer of insulation above the filesystem. Instead, files in the filesystem should have attributes reflecting the various hierarchies or views as the parent responder suggests, in which the file participates: the file and directory hierarchy is but one such view, after all, and this view remains a useful one.
I keep thinking that "callbacks" to application managers that can be registered on individual file changes within the filesystem remain the appropriate architectural model on which to build. Note that I would not necessarily think that individual applications be permitted to directly manage common "hot" files, like configuration files under /etc: the formats differ (though an XML-ized /etc can help here, bootstrapping it is a hassle). Instead, the O/S provides a set of interfaces to manage the configurable aspects it offers: /etc/services, for example, does is not generally edited by packages installers and deinstallers, but rather, an O/S facility is provided to manage changes to it, and other such configuration files: applications, after all, should know the configuraion changes they wish to make to other applications or the operating system.
This reduces the filesystem callback requirements to ones of create, move, or remove alone, and not change. That should simplify things.
Food for thought...
The trouble stems if you have some kind of base package, which is extensible via some kind of plug-in architecture, traditionally implemented with DLLs under Windows, or shared object library repositories under Unix and varients. Do the plugins form their own "application" or are they part of the application which they extend? What if I want to manage groups of plugins from a common source, independent of the applications extended? Do all applications have to be so isolated that they can only rely on a common base operating system that can't be extended by third parties (which would then be locked into their own application spaces)? What about multiple users sharing the same applications: will their saved files be intermingled?
Blech. Sounds like the cure is worse than the disease.
But, nevertheless, the idea of organizing independent applications in a convenient hierarchy is a desirable one. The trouble is that the traditional filesystem only offers a single hierarchy in which to organize them and so we struggle to determine the best hierarchy to use. We really need to organize sets of files that compromise a related unit ("file set", if you will, and "application file set", for the specific case of end-user applications) in multiple hierarchies: a new one created for the file set being added, and existing ones that the file set affects.
"Symlinks!"
What's that?
"Symlinks!"
Well, O.K. symlinks kind of solve this problem: pick a cannonical location in the file system for your file set and symlink secondary links to the appropriate files. This is a good idea, and has been used for ages to separate the reference to a file in the filesystem from where it is actually stored, but there are drawbacks:
1. Symlinks are one-way. Typically you'll have an application directory full of files and subdirectories, and a bunch of links into that directory tree. What happens if you move or delete entries? Oh, woe to the who has broken symlinks.
2. The context in which the symlink is interpreted may restrict where the target may be. Consider startup scripts added under /etc/rc.d/... They' don't do much good if they link to files in filesystems that haven't yet been mounted. Some restriction to where things have to be canonically installed depending on how and when they will be used is apparent. Fortunately, we generally don't have complicated hierarchies of what parts of the filesystem are mounted, but rather just a few: boot, locally mounted, remotely mounted. So, this problem is managable: we can inagine /opt and /usr/opt: the former available on the root filesystem.
3. Application interaction. The trouble with having one application extend the capabilities of another (and the base O/S can be considered as "one application" from the perspective of third party software providers, other than the O/S provider) is that adding, moving, or removing files can or should affect running applications. Ideally, an action which would leave a symlink dangling should be picked up by any running applications that might care and either delayed until the application can cope, or vetoed. (And, I suppose, --force and --async are your friends here). Current practice in most package managers is to have pre-install, post-install, pre-deinstall, and post-deinstall scripts that try to deal with this inter-application issue. The problem is two fold: (1) the things necessary to be communicated to other applications are varied, and (2) the manner in which they are communicated differ between applications (never mind different versions of the same application). Ideally, the inter-application interface that deals with new, removed, or relocated external files should be (a) thin, and (b) supported by t
About corporate power? We can do nothing.
Gee, how defeatist.
Consider, when the product is software, cooperatives have demonstrated that they can give the supposedly efficient mega corporation a damn good run for it's money.
I'm talking, of course, about Tux vs. Microsoft. Microsoft has admitted that Linux is it's biggest threat.
Now, I don't think that Microsoft is going to disappear any time soon, but I do think that the desire for a free operating system had a lot to do with the collaborative effort that made Linux a reality, heck, Windows didn't satisfy Torvalds' view of what an operating system should be and he started to scratch that itch.
"But," I hear the gentle reader protest, "you can't make money writing and giving software away for free."
Perhaps not, but that isn't the point -- I don't rake my yard to make money. I don't organize my house just so to make money. I do these things to make my life easier -- the effort I expend is justified by the benefits I reap. And so it is with free software -- individual investments in tool-building compounded by collaborative network effects "on steroids". We do it to save money, or reduce expenses, in the sense of making our lives easier, rather than increase revenue. Last time I checked, income=revenue-expenses. You don't have to increase revenue to increase income. Inflation causes both revenue and expenses to increase over time, so there is effectively no limit to expense reduction, save time.
The funny thing is that I make my living writing non-free software licensed for millions of dollars to a handful of organizations, and that most people wouldn't even want to be free, as they'd derive no use of it (well, some might be handy to be free to a small minority, and it is a bit of an ethical dilema to keep it non-free, but hey, the market isn't perfectly efficient all the time). Bottom line is that Microsoft isn't going to go away any time soon -- In fact I'd bet on it being around for a while, strengthened by eventually getting out of the areas where Linux shines, though I do think the days that Windows being the vehicle that gives Windows apps a lock on the market are numbered. Buy time, and leverage strength, Bill. I'd go so far as to argue that there wouldn't be Linux, if Windows didn't exist. Necessity, Invention, Mothers. You add them up.
So, the uber-powerful corporation will be reduced, over time, to that which it can continue to do most efficiently or learn to do most efficiently where it hasn't done it before.
The difficulty some face is that they might find the natural time table for this "correction" not to their liking, wishing to use the strong hand of the state to restore "fairness" faster. Funny how wishing for strong governments doesn't always get you what you want, isn't it?
YMMV.
Don't think I would buy the DVD, but it was worth the $5.00 rental, IMHO.
Wonderful title, that, too.
This success, however, is not without the arousal of certain, er, "suspicions".
1. They're "all in one" devices": jacks of all trades, and masters of none.
2, They're "stylish", whatever that means.
So, the question really becomes, "Are there times and places when and where a low powered, good looking computer is appropriate?". The answer, is a resounding, "YES!"
Look no further than the trials and tribulations of those trying to put together an HTPC (Home Theater Personal Computer): Oh the agony of the fan noise, the ugliness of the case, and so on. It doesn't take much to play music, and playing video from common digital sources only takes a bit more "oomph" (actually, very little more, if you have hardware-assisted MPEG2 decoding). Rendering web-pages is child's play, if you can decode MPEG2 video. What else is there that a computer-as-entertainment device needs to do? About the only thing you can't do with a "low power" computer is play the latest uber-game, for lack of video horsepower. Still, one can achive a wonderful level of entertainment convergence even without this capability.
I have a nice, mid-1980s Bang & Olufsen Beosystem 5500 stereo system: receiver, turntable, CD player, and cassette deck. It drives external Carver amps, Bohlender-Graebner Radio 5000 speakers, and a custom-built amplified subwoofer. It rocks, and looks fscking cool! Yes, it cost 2-3 times as much as a system that sounds as good, but a system that sounds noticibly better would cost 10 times as much -- at some point you stop paying for performance and start paying for style, particularly if you want a nice family room. It complements a Sony HD-ready television, HD satellite receiver, and DVD player. Hmm, the "style" starts to suffer from all the stuff interconnected. But, it get's worse.
See, the B&0 CD player and the DVD player take single disks. Oh sure, I could get a CD/DVD jukebox, but they're, well, ugly (I payed for good looks, remember?). Besides, such things didn't exist in 1987, not even for CDs, when I got the stereo. So, I have a custom-built solid oak-and-granite-and-fancy-suspension-system cabinet to "show off" the B&O equipment and house up to 240 CDs, 90 cassettes, and have a shelf for "misc.", er, DVDs, yeah, I anticipated those cases, that's it. It looks great! Ain't I smart (if obnoxious, at this point?).
Well, perhaps, but not really. Like I said, interconnecting all that equipment detracts from the elegance -- it should "look simple". B&O gets this part right. The cabinet is utterly useless for CD number 241 or cassette number 91 (dunno how many DVD cases it can hold). Now, what would be really slick would be nothing other than a single box, connected to TV or alternate display, and external audio amps and speakers, or multichannel receiver.
Gee, sounds like a lifestyle computer, no?
Granted, the "lifestyle" systems currently available, while stylish, aren't really designed for this kind of use. But, the A/V convergence is encouraging. We're starting to see smarter and smarter set top boxes and networked DVD players. Between OTA and satellite television, there aren't that many different standards that need be accomodated (legacy analog, ATSC, and DVB). A one-size-fits-all tuner box, capable of retrieving digital content over the air, via satellite, or LAN (with WAN gateway to the Internet), isn't that much of a stretch any more. Include a DVD/CD drive, and you're done. Heck, there are digital video processors like ATI's Xilleon varients that already do all manner of ATSC, MPEG, with analog output encoding for NTSC, PAL, and SECAM, with a 300 Mhz MIPS processor to boot.
We're not there yet: current offerings are either ugly or awkward to use, or both. Still, that such first generation convergence devices exist at all, together with stylish lifestyle computers suggests that an eventual optimal merger between the two ideas might happen hopefully sooner than later.
Anyone wanna buy a nice hardwood and granite stereo cabinet?