> The IRS is not conspiring to get all your money. It is just company policy.:)
No, in that case it's a conspiracy because they retroactively conspired with Ben Franklin to convince everyone that taxes are something you just have to accept, that nothing can be done ultimately to prevent them, just like death. Also, in order to get to Franklin, the IRS had to involve the NSA (because they control the world's only time machine) and the USPTO (to negotiate the patents Franklin got in exchange for his famous quote). It was one of the largest propaganda conspiracy coups of all time. They also wanted to get John Lennon in on it, but he refused to cooperate; that's why he's dead now...
> I could go on for some time about the things I see on websights that only > make sense if the 'designer' assumed everyone would view it in exactly the > same resolution and setting and browser as he used. I'm just curious as to > WHY that assumption (or any asumption that leads to fixed sized elements) > gets made.
Something like 99% of the time, this is an indication that the web designer in question is trained in art, *not* computer science, and does not understand all of the important conceptual differences between a web page and a printed page. In particular, the whole concept of adaptive layout is lost on these people, because their brains are stuck in what I call Visual Art Mode -- i.e., they are so busy *looking* at the webpage that they are practically incapable of thinking about the logical structure of the information it contains. WYSIWYG HTML editors significantly exacerbate this problem.
> OSS, should have the ability to import data from amazon by scanning the > barcode of the book, cross-platform, including an OPAC.. Suggestions anyone?
That part's easy. A quick hack using WWW::Mechanize could be thrown together in probably under an hour, to retrieve what info is available from Amazon. PAC would take quite a bit longer, because of the sheer amount of functionality involved in a good PAC, but no individual part of it is hard. The cross-platform part does not add more than perhaps 5% at most to the difficulty of the problem, assuming you design that way in the first place. (Trying to retrofit cross-platform onto an existing solution is another matter, of course.)
Doing a good patron services module is another thing. Circulation is a much harder and more complex problem than you would think at first. Then there's cataloging, which is a royal pain...
> But as far as Koha, I was not able to justify even mentioning it to my boss; > I looked at it, and it just plain wouldn't do a lot of what we really needed
I really should add here that I'm not implying there won't be libraries who find it does everything they need; I was just stating what I found to be the case in our situation. We had specific pieces of functionality we were looking for, and Koha did not deliver. If it had been a couple of minor things, I could have thought about implementing them myself (being as I am fairly conversant in Perl and enjoy working in it), but it just wasn't close enough.\
It also would have been a hard sell, even if it did *everything* we wanted, because of support contract issues, but I didn't get to the point of trying to sell it, because I concluded that it was more than I could do to get it doing everything we needed in the kind of timeframe we were looking at. YMMV.
When I was researching this for our library, Koha is the only open-source thing I found (and, I think there was also a fork of Koha, the name of which I forget, but it did not seem to be any better than Koha from what I could determine).
Unfortunately, I also had to conclude that Koha is really not ready for real use. I looked at its capabilities, and it is really not anywhere near the same ballpark, in terms of functionality, let alone polish, as the various proprietary solutions that are available.
We ended up going with GIS/Polaris, mainly because their quote came in some fifteen thousand smackers lower than the next lowest quote. (This may have had something to do with their status as our current vendor, since until now we have been using their Galaxy system, which is pretty solid but now really starting to show its age. If GIS were not our current vendor, their quote may have been more comparable to the others.) In some ways I wanted to go with another solution, but with the Director and Clerk Treasurer spending hours every week fretting about the possibility that the rumors of budget cuts *might* pan out, the larger pricetag was really not palatable.
But as far as Koha, I was not able to justify even mentioning it to my boss; I looked at it, and it just plain wouldn't do a lot of what we really needed; to a great extent, it would actually have been a step *down* from Galaxy, in terms of functionality (though, of course, getting the data into a relational database, as all modern systems do, is a pretty big win; Galaxy was developed in the era when it went without saying that the data would of course be stored in an undocumented custom binary format; but *any* modern system would get us away from that; Polaris uses MS SQL Server. We'll obviously have to stick it in its own subnet and isolate it from everything with a firewall, and I would have preferred Postgres or Oracle, but hey, there's a DBD module for it, so I'll be able to write a Class::DBI wrapper, and that's a *huge* improvement over a proprietary binary format.
> You know, Windows is surprisingly stable if you don't expose it to any > network outside of a fairly draconian LAN
Or let normal users anywhere near it, or run end-user-type applications on it (e.g., instant messaging, the oddball apps that come bundled with consumer-grade peripherals, games, shareware,...), or run Microsoft's internet-related software on it (mainly Outlook or OE, to a lesser extent also IE), or generally do anything else stupid or abusive with it or to it.
Some of that, notably the thing about letting normal users anywhere near it, applies to most if not all operating systems, incidentally. One supposes that the sort of oddball apps that come bundled with consumer hardware would be trouble on any OS, but of course they're only written for Windows (which is no real loss for the rest of us, IMO). Shareware seemed to be more stable under DOS, but maybe that's more a reflection on how shareware development has changed than on the OS.
> a casual reader might be misled into thinking Wikipedia offers an > unbiased perspective
This is not unique to Wikipedia. There is fundamentally no such thing as an unbiased perspective -- the mere phrase is inherently contradictory. *All* encyclopedia articles (all articles, period) contain bias, and many contain rather appalling bias. There is nothing that can be done about this.
For all that, though, encyclopedias are darned useful. Obviously, you have to read them the same way you ought to read anything: with your brain switched on. But an encycledia article is one of the fastest and most convenient ways to get a quick basic idea of a subject, and then if you need to nail down the details, you have some solid leads on what directions to go in your further research. Sometimes you don't even need further research; sometimes, perhaps even often, the basic understanding you can form from reading an encyclopedia article is good enough.
Does that mean that Wikipedia's vetting process is as good as it can be? No, I don't claim that at all. It surely has some problems. But I do claim that it is good enough to be useful, and that no encyclopedia is anywhere near perfect. Maybe someday a project will come along that's a bit better; if so, I'm all for that. Nupedia, as the author admits, floundered at least partly because its process was *too* stringent and complex. Wikipedia's process goes the other way and could perhaps stand to be a little stricter. Still, it's a whole lot better to have the flawed Wikipedia that we have than a Nupedia with no traction, small mindshare, and very few articles. Perhaps at some point in the future a project will take hold that's somewhere in between.
> Your entire argument revolves around the supposed evils of things that can > do what you want, if you let them.
In theory.
So, then, do you want your web browser to provide a DOM method that runs rm -rf ~/ if the user clicks Ok on a dialog box that asks if you want to view enhanced content? What if it runs an arbitrary *nix command, specified by the site, if the user clicks Ok, so that it wouldn't *necessarily* be destructive, but easily could be? That, in a nutshell, is ActiveX.
Of course, if the user wants to download an executable and run it, he always can. But the way ActiveX is presented is rather different from that; it is presented as a rendering component that is just part of the page, and the retrofitted approval dialog is fundamentally no scarrier than the one you get when you use a search engine ("Oh, horrors, you're sending unencrypted information to this website!") Even that dialog has been retrofitted; the original design was for ActiveX controls to be executed automatically. Even with the approval, all the user has to do is tap the Enter key or bump the spacebar, and the system is compromised. This is fundamentally different from choosing to download and deliberately execute something.
Yes, I suppose that in theory, if ActiveX "support" were done in a way that required the user to expressly choose an "Execute ActiveX Programs" item on a menu somewhere in order to start the site's ActiveX controls, and then presented a warning dialog that ActiveX Programs can do whatever they want, and you should only run them if you fully trust the site, and if the buttons were "Trust this site" and "Keep me safe", with the latter being the default, then that could be construed as secure. However, that level of support would not make ActiveX advocates happy (I can hear them now: "Why should the user have to click a menu item?!? Some users wont click it!! I need my sitez ActiveX to run no matter what!!1 Tell me how to do that on my site, or Foxfire sucks!!"), and few other people care (except the people who are actively against it), so it would be kinda pointless.
Let me just close by saying that ActiveX is a *mistake* Microsoft made, *not* a feature. They've attempted to cover over the worst of the problem by retrofitting user approval, but eventually they will discontinue ActiveX support entirely. It is somewhat deprecated already in SP2, will be fully deprecated in Longhorn (which will include a replacement technology) and eventually discontinued, probably in a security-oriented service pack. Even a feature-for-feature clone of Microsoft software (and neither Mozilla nor OpenOffice is intended to be that) would not probably choose to implement ActiveX, unless it were intended to be an *exact*, bug-for-bug type of clone.
> Lack of ActiveX support actually prevented my previous company from switching > to OpenOffice or Mozilla. The attitude that it's better that these two apps > don't support it seriously pisses me off. If Microsoft can't get away with > being arrogant, than the OSS Community can't either.
Arrogance has nothing to do with it; this decision is about (and can only be about) security. Applications that care about security *cannot* support ActiveX, full stop.
It's not just better; it's *VITAL* that they not support ActiveX. If Mozilla for instance did support ActiveX, anyone even the slightest bit conscious of basic security issues would migrate away to another browser immediately (Opera, most likely). If you think ActiveX is a good thing, you have no idea what ActiveX is, or no understanding of security at all. Fundamentally, by design, ActiveX allows any website you visit to do, quite literally, whatever it wants on your computer[1]. A well-behaved site is *supposed* to be nice and just draw stuff in the browser window, but fundamentally it can do whatever it likes, because that's how ActiveX was designed. Microsoft created ActiveX during the era when they considered security to be 100% Somebody Else's Problem, so they didn't give this a second thought; now that they are making some attempt to take security seriously, they regret ever having developed ActiveX in the first place; sooner or later they will have to discontinue support for it in a service pack or upgrade, because there is no secure way to support it.
It was a mistake for Microsoft to develop ActiveX and start supporting it; it would be a mistake for *any* application to support it that doesn't already, and the ones that do already (mainly, MSIE) will eventually have to bite the backward-compatibility bullet and stop supporting it. Mozilla.org absolutely cannot afford to make that kind of mistake; security has been and is one of the major factors driving Firefox adoption; if Firefox supported ActiveX, it would actively lose most of its market share virtually overnight. That kind of wide-open security hole is never EVER worth the risk. OpenOffice *might* be able to get away with it better, because it is used mostly with internal documents, not content off the internet, but it would still be a major security headache, and not supporting ActiveX is still substantially the right decision.
Lack of ActiveX support is not about lack of developer time; it is not about needing to reverse-engineer protocols; it is not about platform parity; it is not about open standards, and it is certainly not about arrogance; it is about security, and it is so essential to security that no other issue can matter.
It is Windows users who would suffer if these applications supported ActiveX on Windows. Yes, Windows has other security problems, but ActiveX dwarfs relatively little things like Shatter attacks (a form of privilege escalation attack that exploits a design flaw in the Win32 API), because it is so much easier to exploit; it is not so much a security vulnerability as a complete abdication of all pretenses of security. Right now, Windows users have a choice; they can use MSIE, and pray nobody ever sends them a link to a site with a less-than-scrupulous webmaster, or they can download a browser with basic security. Don't take that choice away from them.
--- [1] The design has now had user approval retrofitted onto it, so that a site
now can only do whatever it wants after the user frobs the "Ok" button.
But the user (and the computer, for that matter) has no way to tell
before doing so whether the site intends to draw pictures in the browser
window, scroll text across the status bar, or scour the user's Documents
directory for credit card details and other personal information and send
it back to the site. In fact, it's not easy to tell what a site's ActiveX
programs (called "controls" in ActiveX parlance) have done even afterwards.
You know? How do you know? What you meant to say is, "As a high school student, I have been told by the school that in certain cases, schools really do need more money." The school district could use the money, certainly. Most schools (and, for that matter, most other things) could find things to do with more money. Some of them might even be really valuable things. But "need" is such a strong word...
> Our school district is closing schools, cutting programs, and firing > teachers because it simply can't pay for them.
Have you examined the school district's budget in detail? Have you verified that, unlike every other school, they aren't spending upwards of 25% of the budget on less important things than the stuff they're cutting?
Schools routinely use these kinds of tactics to get levies passed: threatening to close schools, cutting programs, and so forth. Often the programs they cut are ones that do not cost the school anything significant to run, because they pay for themselves -- such as a football program, which invariably pays for itself out of ticket sales and usually helps subsidize several other sports (or possibly the band) as well in the bargain. They cut whatever will get the public's attention and get the levy passed. It's politics. There are other things they could cut, that would have less impact on the running of the school, less impact on the community, but they don't cut those things, because that wouldn't get the levy passed.
This isn't to say that there's no value in the things that they're not cutting, that it wouldn't be better to have the money and not have to cut them, but the issue is never as unilateral as the school district wants you to believe. If the cut-the-high-profile-stuff tactic doesn't work, and the community simply refuses to fork over the money, after several years they would find other things to cut. It seldom gets to that point, because when the football goes pay-for-play, the students and parents mount up a grassroots campaign and get the levy passed.
Like I said, I vote for school levies, because it's easier to give the schools more money than to give them what they really need, and if it helps a little bit, great. But don't believe everything they tell you about their finances; they generally make it out to be a *lot* more dire than it actually is.
There are a *few* exceptions, maybe 1% of school districts that struggle financially so badly that they really do have to sit down and figure out how to wrestle the budget into such a state that they can continue to function the next year. But those districts don't threaten things like firing teachers and cutting programs. Those districts talk about how many years they think they can get by before they're going to have to merge with another district, and which other district might be willing to merge with them. We have one of those districts in this area, a few miles up the road. Whenever our school district starts whining about finances and saying they're going to cut programs and close buildings and fire teachers (all of which they're doing right now, after just last year we passed a huge levy for building a new high school), I think about Crestline and remember that on the whole, we haven't got it so bad.
Animated icons? How about animated filenames? Why should filenames be static? It's bad enough filenames can only have certain characters, that they cannot, for instance, contain paragraph breaks. What if I want a three-paragraph-long filename? And why should they be text-only? What is this, 1980? In the modern era, our filenames should be fully liberated to include markup, images, animation, scripts,...
(No, I'm not serious. I don't even like filenames with spaces in them.)
> more tax money doesn't help bad schools, it just makes bad schools > more expensive.
There's truth in that. I generally vote for school levies, but I don't do so under the illusion that it will magically solve the problems. I vote for the levies because I can't give the schools what they really need; more money is something we can give them, relatively easily, so we throw that at the problem and hope it helps a little. But yeah, obviously, it's not fundamentally going to solve the real problems that the schools face. For that to happen, a larger percentage of parents would have to wake up and start *actually* caring about their kids' education, not in some kind of abstract warm fuzzy way but in the rubber-meets-the-road sort of way -- seeing that homework gets done and is understood and all that sort of thing, the sort of things the parents do in the school districts with high average SAT scores. Discussing why the teacher is right (or why the teacher is wrong) in a given instance, and how you know, and what the implications are. Making sure they don't watch more than half a dozen or so hours of television a week. Taking them to the library, helping them pick out good books, discussing what it is about these books that makes them good picks, and how to identify books that are worth reading. You know, educating the kids. That's far more important than making sure they have new clothes in good condition periodically, and far more often neglected.
But, like I said, that's something I can't fix. I can't give the schools more good parents. So I vote for the levies and hope it helps a little.
> Notice: Transylvania is included, but South Africa is not!
There are a number of little things like that. For instance, Scotland, Ireland, and England are included, but not Northern Ireland or Wales. I chalk this up to the fact that they were trying to make it fit the rhythm at least somewhat, as well as rhyme if possible. Also, since you mentioned South Africa, both Swaziland and Lesotho are included, even though South Africa is not. Then there's the small matter of using nonstandard names for some countries (e.g., naming the UAE by the capital city; though I can certainly sympathize with that one, as far as fitting rhythm and rhyming schems is concerned). Borneo, as far as I am aware, was *never* a country, and I'm not so sure about Sumatra either in that respect; Brunei is not included (was it an independent country at the time? it is now...); Tibet was no longer independent when the song was written; the song also lists the Spanish Sahara even while pointing out its demise as a recognized political entity. Another glaring omission on the continent of Africa is the C.A.R. There's also some inconsistency in how countries with similar names are handled; "both Yemens" seems reasonable enough (it is a song after all, so something has to give in the name of poetic license), but "Korea" and "Vietnam" were just listed as if one country each. Also, I am firmly of the opinion that Anvilania should have been squeezed in somehow.
Of course, the whole song is quite obsolete now, as world political geography in certain regions (northern Asia and the Balkans notably) has had quite a number of new lines drawn ad interim. Additionally, most island nations were not included unless they are closely associated with a major continent. Thus, most of Oceania was omitted, and most of the tiny Carribean nations. Between all of that and the breakups of the USSR and Yugoslavia, you could probably write three additional verses if you wanted to include a bunch of the nations that were not included at the time. You could also throw in San Marino (omitted), Eritrea (new), and whatever else strikes your fancy.
> The system stability is unmatched. (sorry to say that, my personal Gentoo > box has more problems than this one).
So, if the most bleeding-edge distro of all is less stable, that means the stability is "unmatched"? Interesting reasoning. (Not that Gentoo isn't a lot of fun and all, but "stable" isn't really what it's about; Gentoo is for people who like to experiment with the latest versions of things. Of course, there's such a thing as too much stability (Woody being a key example), and somewhere in between most of us settle on an amount of stability that's reasonable for our purposes.)
> That's great up until someone releases malware inside your network. > On corporate networks, often 100k plus desktops, it will happen.
If you have 100k plus systems, you should have multiple subnets, isolated from one another by the firewall(s). That doesn't make this a complete non-issue, but it mitigates it significantly.
> if your security is breaking functionality that wasn't a vulnerability in > the first place, it's not really security, it's just a bug
End users can't tell the difference between functionality and a vulnerability. Consider, for instance, a mail client feature that automatically executes executable binary attachments. (This is of course purely hypothetical; no vendor would ever release such a thing, and if they did it would never be popular, and it *certainly* wouldn't be called Marvy Smooth Omicron Email, or anything with similar initials. Ahem.) So, explain to an end user what it does: "If someone sends you a program by email, MSOE automatically runs the program for you." Then ask them whether that's a dangerous bug or a useful feature. Which response you get is going to have a lot to do with the order you put the options in, how you did the explaining, and the tone of voice you use in asking. Because, basically, they don't know.
And Microsoft, in 1995 or thereabouts, didn't care, and so a *lot* of the "features" in their software are inherently dangerous. Fundamental features of their web browser, without which some sites will not display properly. Fundamental features of the Windows API, without which many applications will not run at all, and many more will not run correctly. And so on. Those all have to be broken, but people won't accept that much breakage at once, so it has to be broken down into bits and pieces, a few at a time, spread out over a number of service packs, updates, new OS versions,...
2K/XP had to break compatibility (from 95/98) to give us things like memory protection and multiuser file permissions. Many legacy apps won't run because of this. SP1 broke a couple of things; SP2 breaks some things; Longhorn will break more, and it will be followed by service packs that break some more things, and Blackcomb will break things...
> I wish I had the power to ban applications like that.
A large part of that trick is to do it *before* anyone starts using them. Once an application becomes a part of people's workflow, it becomes a lot more difficult to ban.
> I pray for the day when some really smart person writes replacement code > that will allow a complete switchover from MSIE to Firefox
You mean, make Firefox do whatever is necessary to completely mimic MSIE? But then it would be *vulnerable* in just the same ways as MSIE. For instance, there's no safe solution for ActiveX; the whole design of ActiveX is, the website hands you a random chunk of code, that we call a "control", which is a black box, and there is absolutely now way to know what it does without running it; so you run it, and it (if it is well behaved) draws stuff in the window. If it is not well-behaved, it does whatever it feels like. There's no way (for a computer program) to know without running it. (A highly skilled technical worker could attempt to analyze it, using knowledge of machine code and the Windows API, and potentially figure out what it does. But a web browser cannot do this automatically between the time the user clicks a link and the time the page renders.) The only way to compatibly render it is to turn it loose and let it do whatever it wants. That's the way ActiveX is *designed*. On purpose. Microsoft was not very interested in security in 1995. Now they have developed a story about "trust", and about how it's up to the user to determine whether a given site's controls are trusted, but the bottom line is, if the user frobs "yes" every time, like ninety-some percent of end users do (which is not surprising, given the remarkable similarity between the ActiveX control approval dialog and every other web browser dialog, including the warning you get if you attempt to send "information" (horrors) via a fill-out-form CGI interface that doesn't use SSL -- e.g., if you type something into a search engine box and hit "Search").
Of course, MSIE can (and should) be configured to silently reject these things, and *not* ask the user, and *not* run them, but then sites that rely on custom ActiveX controls will not work, just like in Firefox.
Do you see the problem? ActiveX is just one example of a general trend: Microsoft in the early nineties treated security as a *complete* non-issue, and as a result, security is now incompatible with backward-compatibility. This is a large part of the reason SP2 is not universal; the very act of improving security on a Microsoft system is *guaranteed*, no matter how carefully it is done, to break compatibility all over the place.
If all the insecurities in Microsoft software were due to bugs, like buffer overflows, they wouldn't be having this problem. But most of the worst insecurities are *design* issues, and changing the design is going to break compatibility.
It has to be done. The level of security that was par for Microsoft's course in 1995 is just not acceptable, so backward compatibility is *going* to have to be broken. *Lots* of it. SP2 is just the *beginning*. Longhorn, if it is more secure than WinXP SP2, will break backward compatibility again. The service packs for Longhorn, if they improve security, will break backward compatibility again. Blackcomb, if it improves security, will break backward compatibility again. The service packs for Blackcomb will break it again.
Microsoft is doling this out in small doses like this for a couple of reasons. First, because they're working from an existing codebase, so it'll of course take time to fix many issues -- especially deep-seated design issues. Huge mounds of source code have to be *heavily* refactored and overhauled and in some cases just plain rewritten. The second reason is because customers will only accept so much backward incompatibility at once without jumping ship to another vendor. If Microsoft released a new operating system today that fixed all the major design flaws in their current offering, almost 100% of current apps would *not* run on it; ISVs would balk and refuse to port their applications; customers would refuse to upgrade; OEMs would refuse to ship it; and people would refuse to buy it. If you thought App
He'd had root access -- not just for a few minutes once, but as a regular part of his everyday job -- and the worst he could do was install some trojans that got him noticed and caught? Yeesh; maybe it's good that he was an *ex* admin.
You don't *give* people root access if you don't trust them, because once they've had it, you have to assume they still have it, until you replace the system (well, or re-install completely from scratch, but in practice that usually only happens when you replace the thing).
And yes, you do have to have an admin and give him root access. But if at any point you decide you don't trust him, you have a serious problem. The company in the case you're talking about got off easy.
> Although the temptation is pretty high on that gear, imagine forcing all > the top channels in a community to start playing monty python and the > holy grail at midnight.
Monty Python? Why think small? Make 'em all play car dealership commercials in an infinite loop!
> Anarctica is economically off limits due to treaty. It has oil, minerals, > fish resources, and fresh water that might otherwise be exploited (the oil > and fish probably would).
The fish are not inland. The southern ocean is (apart from the treaty) ecconomically exploitable. The inland part of the continent is not. Harvesting things there would be, quite apart from the treaty, significantly uneconomic. Yes, there are valuable resources, but the cost of harvesting them is too high. (This is inland; I'm not sure about the peninsula and immediate coastal regions.)
> Obviously, the Moon and Mars don't come close to having the relatively > friendly environment of Anarctica, but they aren't "completely worthless".
I only said they were *economically* worthless. I was very careful to qualify that statement that way every time I made it. And I might add that I meant at our current level of technology; in a couple hundred years, who knows? But meanwhile, they're scientifically interesting.
Oh, yeah, perfect in the sense that... * The text will not rewrap to fit the window width. * Ignoring all pretenses of following accessibility guidelines, every
PDF viewer in the known universe, including every version of Acrobat
Reader, displays the text in on-paper colors rather than adhering to
the system colors. (This is a deal-breaker for anyone whose eyes are
sensitive to light; the blinding white backgrounds on a luminescent
medium like a computer screen make us go snowblind in short order
and give us migraines if we try to put up with them for very long.) * Basic features like clipboard copy and search often don't work.
> KDE and gnome already have that kind of stuff built in
Not last I checked. They have some configuration stuff, but the Gnome/KDE config stuff does not, for the most part, duplicate the *drake tools, unless I'm missing something. The X server may come with XF86Config or somesuch, but XFdrake is better. CUPS comes with what passes for a config tool, but, unless it has improved quite a lot recently, printerdrake makes it look outright bad. rpmdrake also compares very favorably to any other GUI RPM package manager out there.
One only hopes they don't rename them all now... XFdriva, printerdriva (or perhaps printadriva (eww)), rpmdriva,...
Slashdot Mirror
> The IRS is not conspiring to get all your money. It is just company policy. :)
No, in that case it's a conspiracy because they retroactively conspired with Ben Franklin to convince everyone that taxes are something you just have to accept, that nothing can be done ultimately to prevent them, just like death. Also, in order to get to Franklin, the IRS had to involve the NSA (because they control the world's only time machine) and the USPTO (to negotiate the patents Franklin got in exchange for his famous quote). It was one of the largest propaganda conspiracy coups of all time. They also wanted to get John Lennon in on it, but he refused to cooperate; that's why he's dead now...
Umm, let me get this straight: you want to build a computer in a *toilet* case?
> I could go on for some time about the things I see on websights that only
> make sense if the 'designer' assumed everyone would view it in exactly the
> same resolution and setting and browser as he used. I'm just curious as to
> WHY that assumption (or any asumption that leads to fixed sized elements)
> gets made.
Something like 99% of the time, this is an indication that the web designer in question is trained in art, *not* computer science, and does not understand all of the important conceptual differences between a web page and a printed page. In particular, the whole concept of adaptive layout is lost on these people, because their brains are stuck in what I call Visual Art Mode -- i.e., they are so busy *looking* at the webpage that they are practically incapable of thinking about the logical structure of the information it contains. WYSIWYG HTML editors significantly exacerbate this problem.
> OSS, should have the ability to import data from amazon by scanning the
> barcode of the book, cross-platform, including an OPAC.. Suggestions anyone?
That part's easy. A quick hack using WWW::Mechanize could be thrown together in probably under an hour, to retrieve what info is available from Amazon. PAC would take quite a bit longer, because of the sheer amount of functionality involved in a good PAC, but no individual part of it is hard. The cross-platform part does not add more than perhaps 5% at most to the difficulty of the problem, assuming you design that way in the first place. (Trying to retrofit cross-platform onto an existing solution is another matter, of course.)
Doing a good patron services module is another thing. Circulation is a much harder and more complex problem than you would think at first. Then there's cataloging, which is a royal pain...
> But as far as Koha, I was not able to justify even mentioning it to my boss;
> I looked at it, and it just plain wouldn't do a lot of what we really needed
I really should add here that I'm not implying there won't be libraries who find it does everything they need; I was just stating what I found to be the case in our situation. We had specific pieces of functionality we were looking for, and Koha did not deliver. If it had been a couple of minor things, I could have thought about implementing them myself (being as I am fairly conversant in Perl and enjoy working in it), but it just wasn't close enough.\
It also would have been a hard sell, even if it did *everything* we wanted, because of support contract issues, but I didn't get to the point of trying to sell it, because I concluded that it was more than I could do to get it doing everything we needed in the kind of timeframe we were looking at. YMMV.
When I was researching this for our library, Koha is the only open-source thing I found (and, I think there was also a fork of Koha, the name of which I forget, but it did not seem to be any better than Koha from what I could determine).
Unfortunately, I also had to conclude that Koha is really not ready for real use. I looked at its capabilities, and it is really not anywhere near the same ballpark, in terms of functionality, let alone polish, as the various proprietary solutions that are available.
We ended up going with GIS/Polaris, mainly because their quote came in some fifteen thousand smackers lower than the next lowest quote. (This may have had something to do with their status as our current vendor, since until now we have been using their Galaxy system, which is pretty solid but now really starting to show its age. If GIS were not our current vendor, their quote may have been more comparable to the others.) In some ways I wanted to go with another solution, but with the Director and Clerk Treasurer spending hours every week fretting about the possibility that the rumors of budget cuts *might* pan out, the larger pricetag was really not palatable.
But as far as Koha, I was not able to justify even mentioning it to my boss; I looked at it, and it just plain wouldn't do a lot of what we really needed; to a great extent, it would actually have been a step *down* from Galaxy, in terms of functionality (though, of course, getting the data into a relational database, as all modern systems do, is a pretty big win; Galaxy was developed in the era when it went without saying that the data would of course be stored in an undocumented custom binary format; but *any* modern system would get us away from that; Polaris uses MS SQL Server. We'll obviously have to stick it in its own subnet and isolate it from everything with a firewall, and I would have preferred Postgres or Oracle, but hey, there's a DBD module for it, so I'll be able to write a Class::DBI wrapper, and that's a *huge* improvement over a proprietary binary format.
> You know, Windows is surprisingly stable if you don't expose it to any
...), or run Microsoft's internet-related software on it (mainly Outlook or OE, to a lesser extent also IE), or generally do anything else stupid or abusive with it or to it.
> network outside of a fairly draconian LAN
Or let normal users anywhere near it, or run end-user-type applications on it (e.g., instant messaging, the oddball apps that come bundled with consumer-grade peripherals, games, shareware,
Some of that, notably the thing about letting normal users anywhere near it, applies to most if not all operating systems, incidentally. One supposes that the sort of oddball apps that come bundled with consumer hardware would be trouble on any OS, but of course they're only written for Windows (which is no real loss for the rest of us, IMO). Shareware seemed to be more stable under DOS, but maybe that's more a reflection on how shareware development has changed than on the OS.
> a casual reader might be misled into thinking Wikipedia offers an
> unbiased perspective
This is not unique to Wikipedia. There is fundamentally no such thing as an unbiased perspective -- the mere phrase is inherently contradictory. *All* encyclopedia articles (all articles, period) contain bias, and many contain rather appalling bias. There is nothing that can be done about this.
For all that, though, encyclopedias are darned useful. Obviously, you have to read them the same way you ought to read anything: with your brain switched on. But an encycledia article is one of the fastest and most convenient ways to get a quick basic idea of a subject, and then if you need to nail down the details, you have some solid leads on what directions to go in your further research. Sometimes you don't even need further research; sometimes, perhaps even often, the basic understanding you can form from reading an encyclopedia article is good enough.
Does that mean that Wikipedia's vetting process is as good as it can be? No, I don't claim that at all. It surely has some problems. But I do claim that it is good enough to be useful, and that no encyclopedia is anywhere near perfect. Maybe someday a project will come along that's a bit better; if so, I'm all for that. Nupedia, as the author admits, floundered at least partly because its process was *too* stringent and complex. Wikipedia's process goes the other way and could perhaps stand to be a little stricter. Still, it's a whole lot better to have the flawed Wikipedia that we have than a Nupedia with no traction, small mindshare, and very few articles. Perhaps at some point in the future a project will take hold that's somewhere in between.
> Your entire argument revolves around the supposed evils of things that can
> do what you want, if you let them.
In theory.
So, then, do you want your web browser to provide a DOM method that runs rm -rf ~/ if the user clicks Ok on a dialog box that asks if you want to view enhanced content? What if it runs an arbitrary *nix command, specified by the site, if the user clicks Ok, so that it wouldn't *necessarily* be destructive, but easily could be? That, in a nutshell, is ActiveX.
Of course, if the user wants to download an executable and run it, he always can. But the way ActiveX is presented is rather different from that; it is presented as a rendering component that is just part of the page, and the retrofitted approval dialog is fundamentally no scarrier than the one you get when you use a search engine ("Oh, horrors, you're sending unencrypted information to this website!") Even that dialog has been retrofitted; the original design was for ActiveX controls to be executed automatically. Even with the approval, all the user has to do is tap the Enter key or bump the spacebar, and the system is compromised. This is fundamentally different from choosing to download and deliberately execute something.
Yes, I suppose that in theory, if ActiveX "support" were done in a way that required the user to expressly choose an "Execute ActiveX Programs" item on a menu somewhere in order to start the site's ActiveX controls, and then presented a warning dialog that ActiveX Programs can do whatever they want, and you should only run them if you fully trust the site, and if the buttons were "Trust this site" and "Keep me safe", with the latter being the default, then that could be construed as secure. However, that level of support would not make ActiveX advocates happy (I can hear them now: "Why should the user have to click a menu item?!? Some users wont click it!! I need my sitez ActiveX to run no matter what!!1 Tell me how to do that on my site, or Foxfire sucks!!"), and few other people care (except the people who are actively against it), so it would be kinda pointless.
Let me just close by saying that ActiveX is a *mistake* Microsoft made, *not* a feature. They've attempted to cover over the worst of the problem by retrofitting user approval, but eventually they will discontinue ActiveX support entirely. It is somewhat deprecated already in SP2, will be fully deprecated in Longhorn (which will include a replacement technology) and eventually discontinued, probably in a security-oriented service pack. Even a feature-for-feature clone of Microsoft software (and neither Mozilla nor OpenOffice is intended to be that) would not probably choose to implement ActiveX, unless it were intended to be an *exact*, bug-for-bug type of clone.
> Lack of ActiveX support actually prevented my previous company from switching
> to OpenOffice or Mozilla. The attitude that it's better that these two apps
> don't support it seriously pisses me off. If Microsoft can't get away with
> being arrogant, than the OSS Community can't either.
Arrogance has nothing to do with it; this decision is about (and can only be about) security. Applications that care about security *cannot* support ActiveX, full stop.
It's not just better; it's *VITAL* that they not support ActiveX. If Mozilla for instance did support ActiveX, anyone even the slightest bit conscious of basic security issues would migrate away to another browser immediately (Opera, most likely). If you think ActiveX is a good thing, you have no idea what ActiveX is, or no understanding of security at all. Fundamentally, by design, ActiveX allows any website you visit to do, quite literally, whatever it wants on your computer[1]. A well-behaved site is *supposed* to be nice and just draw stuff in the browser window, but fundamentally it can do whatever it likes, because that's how ActiveX was designed. Microsoft created ActiveX during the era when they considered security to be 100% Somebody Else's Problem, so they didn't give this a second thought; now that they are making some attempt to take security seriously, they regret ever having developed ActiveX in the first place; sooner or later they will have to discontinue support for it in a service pack or upgrade, because there is no secure way to support it.
It was a mistake for Microsoft to develop ActiveX and start supporting it; it would be a mistake for *any* application to support it that doesn't already, and the ones that do already (mainly, MSIE) will eventually have to bite the backward-compatibility bullet and stop supporting it. Mozilla.org absolutely cannot afford to make that kind of mistake; security has been and is one of the major factors driving Firefox adoption; if Firefox supported ActiveX, it would actively lose most of its market share virtually overnight. That kind of wide-open security hole is never EVER worth the risk. OpenOffice *might* be able to get away with it better, because it is used mostly with internal documents, not content off the internet, but it would still be a major security headache, and not supporting ActiveX is still substantially the right decision.
Lack of ActiveX support is not about lack of developer time; it is not about needing to reverse-engineer protocols; it is not about platform parity; it is not about open standards, and it is certainly not about arrogance; it is about security, and it is so essential to security that no other issue can matter.
It is Windows users who would suffer if these applications supported ActiveX on Windows. Yes, Windows has other security problems, but ActiveX dwarfs relatively little things like Shatter attacks (a form of privilege escalation attack that exploits a design flaw in the Win32 API), because it is so much easier to exploit; it is not so much a security vulnerability as a complete abdication of all pretenses of security. Right now, Windows users have a choice; they can use MSIE, and pray nobody ever sends them a link to a site with a less-than-scrupulous webmaster, or they can download a browser with basic security. Don't take that choice away from them.
---
[1] The design has now had user approval retrofitted onto it, so that a site
now can only do whatever it wants after the user frobs the "Ok" button.
But the user (and the computer, for that matter) has no way to tell
before doing so whether the site intends to draw pictures in the browser
window, scroll text across the status bar, or scour the user's Documents
directory for credit card details and other personal information and send
it back to the site. In fact, it's not easy to tell what a site's ActiveX
programs (called "controls" in ActiveX parlance) have done even afterwards.
> if wikipedia has officially supplanted the great Encyclopedia Galactica
> as the standard repository of all knowledge and wisdom yet.
I think Wikipedia is not nearly as much like the Encyclopedia Galactica as it is like the Hitchhiker's Guide.
> Speaking as a high school student, I know
You know? How do you know? What you meant to say is, "As a high school student, I have been told by the school that in certain cases, schools really do need more money." The school district could use the money, certainly. Most schools (and, for that matter, most other things) could find things to do with more money. Some of them might even be really valuable things. But "need" is such a strong word...
> Our school district is closing schools, cutting programs, and firing
> teachers because it simply can't pay for them.
Have you examined the school district's budget in detail? Have you verified that, unlike every other school, they aren't spending upwards of 25% of the budget on less important things than the stuff they're cutting?
Schools routinely use these kinds of tactics to get levies passed: threatening to close schools, cutting programs, and so forth. Often the programs they cut are ones that do not cost the school anything significant to run, because they pay for themselves -- such as a football program, which invariably pays for itself out of ticket sales and usually helps subsidize several other sports (or possibly the band) as well in the bargain. They cut whatever will get the public's attention and get the levy passed. It's politics. There are other things they could cut, that would have less impact on the running of the school, less impact on the community, but they don't cut those things, because that wouldn't get the levy passed.
This isn't to say that there's no value in the things that they're not cutting, that it wouldn't be better to have the money and not have to cut them, but the issue is never as unilateral as the school district wants you to believe. If the cut-the-high-profile-stuff tactic doesn't work, and the community simply refuses to fork over the money, after several years they would find other things to cut. It seldom gets to that point, because when the football goes pay-for-play, the students and parents mount up a grassroots campaign and get the levy passed.
Like I said, I vote for school levies, because it's easier to give the schools more money than to give them what they really need, and if it helps a little bit, great. But don't believe everything they tell you about their finances; they generally make it out to be a *lot* more dire than it actually is.
There are a *few* exceptions, maybe 1% of school districts that struggle financially so badly that they really do have to sit down and figure out how to wrestle the budget into such a state that they can continue to function the next year. But those districts don't threaten things like firing teachers and cutting programs. Those districts talk about how many years they think they can get by before they're going to have to merge with another district, and which other district might be willing to merge with them. We have one of those districts in this area, a few miles up the road. Whenever our school district starts whining about finances and saying they're going to cut programs and close buildings and fire teachers (all of which they're doing right now, after just last year we passed a huge levy for building a new high school), I think about Crestline and remember that on the whole, we haven't got it so bad.
> And God save us from animated icons.
...
Animated icons? How about animated filenames? Why should filenames be static? It's bad enough filenames can only have certain characters, that they cannot, for instance, contain paragraph breaks. What if I want a three-paragraph-long filename? And why should they be text-only? What is this, 1980? In the modern era, our filenames should be fully liberated to include markup, images, animation, scripts,
(No, I'm not serious. I don't even like filenames with spaces in them.)
> more tax money doesn't help bad schools, it just makes bad schools
> more expensive.
There's truth in that. I generally vote for school levies, but I don't do so under the illusion that it will magically solve the problems. I vote for the levies because I can't give the schools what they really need; more money is something we can give them, relatively easily, so we throw that at the problem and hope it helps a little. But yeah, obviously, it's not fundamentally going to solve the real problems that the schools face. For that to happen, a larger percentage of parents would have to wake up and start *actually* caring about their kids' education, not in some kind of abstract warm fuzzy way but in the rubber-meets-the-road sort of way -- seeing that homework gets done and is understood and all that sort of thing, the sort of things the parents do in the school districts with high average SAT scores. Discussing why the teacher is right (or why the teacher is wrong) in a given instance, and how you know, and what the implications are. Making sure they don't watch more than half a dozen or so hours of television a week. Taking them to the library, helping them pick out good books, discussing what it is about these books that makes them good picks, and how to identify books that are worth reading. You know, educating the kids. That's far more important than making sure they have new clothes in good condition periodically, and far more often neglected.
But, like I said, that's something I can't fix. I can't give the schools more good parents. So I vote for the levies and hope it helps a little.
> Notice: Transylvania is included, but South Africa is not!
There are a number of little things like that. For instance, Scotland, Ireland, and England are included, but not Northern Ireland or Wales. I chalk this up to the fact that they were trying to make it fit the rhythm at least somewhat, as well as rhyme if possible. Also, since you mentioned South Africa, both Swaziland and Lesotho are included, even though South Africa is not. Then there's the small matter of using nonstandard names for some countries (e.g., naming the UAE by the capital city; though I can certainly sympathize with that one, as far as fitting rhythm and rhyming schems is concerned). Borneo, as far as I am aware, was *never* a country, and I'm not so sure about Sumatra either in that respect; Brunei is not included (was it an independent country at the time? it is now...); Tibet was no longer independent when the song was written; the song also lists the Spanish Sahara even while pointing out its demise as a recognized political entity. Another glaring omission on the continent of Africa is the C.A.R. There's also some inconsistency in how countries with similar names are handled; "both Yemens" seems reasonable enough (it is a song after all, so something has to give in the name of poetic license), but "Korea" and "Vietnam" were just listed as if one country each. Also, I am firmly of the opinion that Anvilania should have been squeezed in somehow.
Of course, the whole song is quite obsolete now, as world political geography in certain regions (northern Asia and the Balkans notably) has had quite a number of new lines drawn ad interim. Additionally, most island nations were not included unless they are closely associated with a major continent. Thus, most of Oceania was omitted, and most of the tiny Carribean nations. Between all of that and the breakups of the USSR and Yugoslavia, you could probably write three additional verses if you wanted to include a bunch of the nations that were not included at the time. You could also throw in San Marino (omitted), Eritrea (new), and whatever else strikes your fancy.
> The system stability is unmatched. (sorry to say that, my personal Gentoo
> box has more problems than this one).
So, if the most bleeding-edge distro of all is less stable, that means the stability is "unmatched"? Interesting reasoning. (Not that Gentoo isn't a lot of fun and all, but "stable" isn't really what it's about; Gentoo is for people who like to experiment with the latest versions of things. Of course, there's such a thing as too much stability (Woody being a key example), and somewhere in between most of us settle on an amount of stability that's reasonable for our purposes.)
> That's great up until someone releases malware inside your network.
> On corporate networks, often 100k plus desktops, it will happen.
If you have 100k plus systems, you should have multiple subnets, isolated from one another by the firewall(s). That doesn't make this a complete non-issue,
but it mitigates it significantly.
> if your security is breaking functionality that wasn't a vulnerability in
...
> the first place, it's not really security, it's just a bug
End users can't tell the difference between functionality and a vulnerability. Consider, for instance, a mail client feature that automatically executes executable binary attachments. (This is of course purely hypothetical; no vendor would ever release such a thing, and if they did it would never be popular, and it *certainly* wouldn't be called Marvy Smooth Omicron Email, or anything with similar initials. Ahem.) So, explain to an end user what it does: "If someone sends you a program by email, MSOE automatically runs the program for you." Then ask them whether that's a dangerous bug or a useful feature. Which response you get is going to have a lot to do with the order you put the options in, how you did the explaining, and the tone of voice you use in asking. Because, basically, they don't know.
And Microsoft, in 1995 or thereabouts, didn't care, and so a *lot* of the "features" in their software are inherently dangerous. Fundamental features of their web browser, without which some sites will not display properly. Fundamental features of the Windows API, without which many applications will not run at all, and many more will not run correctly. And so on. Those all have to be broken, but people won't accept that much breakage at once, so it has to be broken down into bits and pieces, a few at a time, spread out over a number of service packs, updates, new OS versions,
2K/XP had to break compatibility (from 95/98) to give us things like memory protection and multiuser file permissions. Many legacy apps won't run because of this. SP1 broke a couple of things; SP2 breaks some things; Longhorn will break more, and it will be followed by service packs that break some more things, and Blackcomb will break things...
> I wish I had the power to ban applications like that.
A large part of that trick is to do it *before* anyone starts using them.
Once an application becomes a part of people's workflow, it becomes a lot
more difficult to ban.
> I pray for the day when some really smart person writes replacement code
> that will allow a complete switchover from MSIE to Firefox
You mean, make Firefox do whatever is necessary to completely mimic MSIE? But then it would be *vulnerable* in just the same ways as MSIE. For instance, there's no safe solution for ActiveX; the whole design of ActiveX is, the website hands you a random chunk of code, that we call a "control", which is a black box, and there is absolutely now way to know what it does without running it; so you run it, and it (if it is well behaved) draws stuff in the window. If it is not well-behaved, it does whatever it feels like. There's no way (for a computer program) to know without running it. (A highly skilled technical worker could attempt to analyze it, using knowledge of machine code and the Windows API, and potentially figure out what it does. But a web browser cannot do this automatically between the time the user clicks a link and the time the page renders.) The only way to compatibly render it is to turn it loose and let it do whatever it wants. That's the way ActiveX is *designed*. On purpose. Microsoft was not very interested in security in 1995. Now they have developed a story about "trust", and about how it's up to the user to determine whether a given site's controls are trusted, but the bottom line is, if the user frobs "yes" every time, like ninety-some percent of end users do (which is not surprising, given the remarkable similarity between the ActiveX control approval dialog and every other web browser dialog, including the warning you get if you attempt to send "information" (horrors) via a fill-out-form CGI interface that doesn't use SSL -- e.g., if you type something into a search engine box and hit "Search").
Of course, MSIE can (and should) be configured to silently reject these things, and *not* ask the user, and *not* run them, but then sites that rely on custom ActiveX controls will not work, just like in Firefox.
Do you see the problem? ActiveX is just one example of a general trend: Microsoft in the early nineties treated security as a *complete* non-issue, and as a result, security is now incompatible with backward-compatibility. This is a large part of the reason SP2 is not universal; the very act of improving security on a Microsoft system is *guaranteed*, no matter how carefully it is done, to break compatibility all over the place.
If all the insecurities in Microsoft software were due to bugs, like buffer overflows, they wouldn't be having this problem. But most of the worst insecurities are *design* issues, and changing the design is going to break compatibility.
It has to be done. The level of security that was par for Microsoft's course in 1995 is just not acceptable, so backward compatibility is *going* to have to be broken. *Lots* of it. SP2 is just the *beginning*. Longhorn, if it is more secure than WinXP SP2, will break backward compatibility again. The service packs for Longhorn, if they improve security, will break backward compatibility again. Blackcomb, if it improves security, will break backward compatibility again. The service packs for Blackcomb will break it again.
Microsoft is doling this out in small doses like this for a couple of reasons. First, because they're working from an existing codebase, so it'll of course take time to fix many issues -- especially deep-seated design issues. Huge mounds of source code have to be *heavily* refactored and overhauled and in some cases just plain rewritten. The second reason is because customers will only accept so much backward incompatibility at once without jumping ship to another vendor. If Microsoft released a new operating system today that fixed all the major design flaws in their current offering, almost 100% of current apps would *not* run on it; ISVs would balk and refuse to port their applications; customers would refuse to upgrade; OEMs would refuse to ship it; and people would refuse to buy it. If you thought App
Waitasec...
He'd had root access -- not just for a few minutes once, but as a regular part of his everyday job -- and the worst he could do was install some trojans that got him noticed and caught? Yeesh; maybe it's good that he was an *ex* admin.
You don't *give* people root access if you don't trust them, because once they've had it, you have to assume they still have it, until you replace the system (well, or re-install completely from scratch, but in practice that usually only happens when you replace the thing).
And yes, you do have to have an admin and give him root access. But if at any point you decide you don't trust him, you have a serious problem. The company in the case you're talking about got off easy.
> Although the temptation is pretty high on that gear, imagine forcing all
> the top channels in a community to start playing monty python and the
> holy grail at midnight.
Monty Python? Why think small? Make 'em all play car dealership commercials in an infinite loop!
> Anarctica is economically off limits due to treaty. It has oil, minerals,
> fish resources, and fresh water that might otherwise be exploited (the oil
> and fish probably would).
The fish are not inland. The southern ocean is (apart from the treaty) ecconomically exploitable. The inland part of the continent is not. Harvesting things there would be, quite apart from the treaty, significantly uneconomic. Yes, there are valuable resources, but the cost of harvesting them is too high. (This is inland; I'm not sure about the peninsula and immediate coastal regions.)
> Obviously, the Moon and Mars don't come close to having the relatively
> friendly environment of Anarctica, but they aren't "completely worthless".
I only said they were *economically* worthless. I was very careful to qualify that statement that way every time I made it. And I might add that I meant at our current level of technology; in a couple hundred years, who knows? But meanwhile, they're scientifically interesting.
> PDF's are perfect for online viewing
Oh, yeah, perfect in the sense that...
* The text will not rewrap to fit the window width.
* Ignoring all pretenses of following accessibility guidelines, every
PDF viewer in the known universe, including every version of Acrobat
Reader, displays the text in on-paper colors rather than adhering to
the system colors. (This is a deal-breaker for anyone whose eyes are
sensitive to light; the blinding white backgrounds on a luminescent
medium like a computer screen make us go snowblind in short order
and give us migraines if we try to put up with them for very long.)
* Basic features like clipboard copy and search often don't work.
> KDE and gnome already have that kind of stuff built in
...
Not last I checked. They have some configuration stuff, but the Gnome/KDE config stuff does not, for the most part, duplicate the *drake tools, unless I'm missing something. The X server may come with XF86Config or somesuch, but XFdrake is better. CUPS comes with what passes for a config tool, but, unless it has improved quite a lot recently, printerdrake makes it look outright bad. rpmdrake also compares very favorably to any other GUI RPM package manager out there.
One only hopes they don't rename them all now... XFdriva, printerdriva (or perhaps printadriva (eww)), rpmdriva,