Refcounting can't collect everything if you have any circular references. It's what Perl5 has, and we live with it, but Perl6 is getting real garbage collection (mark-and-sweep I think, or at any rate something more advanced than refcounting).
> I think with hindsight one really has to admit that "certain people" were > absolutely right,
To say that for sure, I'd have to know more than I do about the details of the licensing of Qt at the time. All I really know is that RMS didn't consider it free enough; that in itself doesn't mean for sure to me that it was unsuitable; it raises questions, but that's all; there are things that are plenty free enough for me but not for RMS. Game software like D1X and D2X and njudge that are open-source (in the sense that you can make and distribute changed versions under the same terms under which you received it) but are licensed for non-commercial use only (who needs to use a game commercially?), software licensed in a way that allows only the original author to link it against proprietary extensions (but anyone can distribute it without doing so, just as with GPLed software), and frankly sometimes I wonder whether RMS really thinks the BSD license is quite free enough.
Like I said, I don't know the details of the old Qt license, so I don't know whether it was free enough for me; maybe it wasn't, I don't know. (I also don't have a vested personal interest in finding out, since it's historical now anyway and also because the KDE panel doesn't have drawers, which are an essential feature for me, which is why I use Gnome.) I only know that it wasn't free enough for RMS. (And that there were some who agreed with him, as of course there always are; hence, "certain people" in the plural.)
And frankly, it wasn't important to my post either. As far as being a reason why Gnome was started and was based on GTK instead, the fact that it wasn't free enough for RMS was really enough. It isn't really significant whether he was right about that, in terms of the effect that his stance had on the subsequent developments I discussed.
So that's why I only said what I said, and didn't elaborate.
I have to reinstall Windows often enough at work that I've got an actual
checklist.
(Caveat: this was written for Win95 originally; it's been updated some,
but some parts are obsolete for more current versions.)
Most of it is stuff other than applications, but there are some apps on
the list...
Mozilla
Manufacturer drivers for all hardware (does this count?)
Microsoft's Core Fonts (especially: Verdana and Andale Mono)
something to open zipfiles if the version of Windows in question
doesn't have Compressed Folders.
Irfanview and/or Gimp
PFE32. (If it were a system I were going to use,
I'd go for NTEmacs instead.)
Microsoft PowerToys and/or TweakUI. Windows isn't finished being
installed until this is installed.
> One is a complete Microsoft fanatic, and the other is a totally rabid > anti-MS Linux & BSD fanatic. Thet get along great at work
Of course they get along great -- each one does all the work the other one doesn't want to get stuck with. The Linux/BSD guy never has to touch regedit, and the MS guy never has to edit a config file. Good arrangement.
> I doubt many employers want a mediocre jack-of-all-trades kind of guy.
Think: small employers. Look for employers with 10-50 employees _total_, and you'll find the places that want a TCG[1]. They only hire 0-2 IT guys each, but there are a lot of these places, so in theory there are quite a few TCG positions available. The problem is, of course, that right now most of the people who already have these jobs aren't quitting to move onto greener pastures elsewhere, because jobs are hard to find. (I, for example, am right now holding onto my TCG position for dear life, even though when I took it in 2000 my goal was to keep the job for "at least two years", put it on my resume, and look for something more advanced.) But that's true for people with a more focused skillset, too; IT jobs in general are scarce right now. (Heck, around here just about any kind of white-collar job is currently seeming quite a lot like a hen's tooth, although it's not quite as bad as it was about a year ago or so, and the blue-collar sector has picked up quite a bit already, which is a positive omen.)
[1] The Computer Guy -- i.e., one-man IT department. The official job title
and job position vary greatly, but in practice your basic job position is
"do all the computer stuff". You'll help other staff when they don't
know how to get an attachment or copy and paste something; you'll unstick
printers; you'll set up and administer databases and web servers and
maybe mail servers; you'll purchase and install new computer and network
equipment, assign IP numbers, and coordinate with the overall boss to
develop IT policy. You'll make the phone calls and fill out the RMAs
when things go bad under warrantee, and when things aren't under warantee
you'll figure out exactly what parts you need, get a purchase order from
the accounting person, order the parts, and install them. You'll change
screensavers and rotate wallpaper. You'll upgrade software, help
determine hardware upgrade cycles (in terms of timespan), and when it's
time to do hardware upgrades you'll pick out the new stuff, order it, and
install it when it arrives. You'll look stuff up on the internet for
staff who weren't able to find it, and you'll create and print documents
for staff who aren't comfortable doing that. Occasionally you'll get
stuck with data entry. If they discover that you can do digital
photography and desktop publishing, you'll end up doing that too.
You'll find tactful ways to explain PEBCAK errors without making people
feel stupid, and you'll change toner cartridges, write backup scripts
and arrange for them to run regularly, write other scripts to do various
other convenient things. You'll create custom reports, and you'll write
scripts that generate a given report automatically. Basically, if it
involves a computer and someone doesn't feel comfortable doing it, it
becomes your job. If you do a good job and don't make people feel stupid,
the other staff will think you're wonderful.
> there's got to be a reason why KDE developers chose to write their own > from scratch rather than integrate Gecko.
Mozilla wasn't really ready for primetime yet when they started working on Konqueror, and there was some doubt in some circles whether it ever would be. If they were starting Konqueror from scratch now, they probably would embed Gecko rather than creating KHTML, which would put Konqueror in the same category as Galeon and Chimera. On the other hand, if Gnome and Gimp were starting now they might've used Qt (or, indeed, might not have been started at all, if KDE already existed), but at the time Qt wasn't Free enough to suit certain people -- hence, GTK and Gnome. (It would be nice if a theme selection/creation/application engine existed that themed both of them together -- preferably it should theme both Gnome1 and Gnome2 applications as well as KDE ones. And other kinds of integration, like supporting one another's panel apps and whatnot, is good too.)
Personally, I'm glad we have both Gnome and KDE and that they're different, because I like having more than one good choice. (Yeah, there are other choices; some of them are even almost featureful...) A certain amount of duplication of effort is good, because it creates choice. It is possible to go too far, though, and if all the browsers you mention were complete duplication of effort that would be bad. As it happens, though, there are basically two OSS graphical browser layout engines (that matter): Gecko, and KHTML. Almost all of the browsers use one or the other, so that cuts down quite a bit on the duplication of effort. Yeah, there's duplication in the front-end interface stuff (toolbars and whatnot), but at least they're not reinventing the whole browser layout engine.
SYN floods can be rendered mostly ineffective. Google for "syn cookies" or read Steve Gibson's writeups on DDOS attacks. ACK floods (reflection attacks) are a somewhat larger problem, because they work by consuming bandwidth. The two main ways to protect against those are by filtering ACK packets (which only works for systems that don't need to initiate connections) or by getting a new IP address any time it happens (presumably via DHCP). The former is untenable for client systems, and the latter is mostly untenable for servers. (A system that needs to be both a client and a server could be very hard to protect.)
This RST attack is interesting; I wouldn't want to be ignorant of it, certainly, given that part of my job is network administration. I don't administer any routers or domain servers, however; I deal mostly with http, which tends to use such short-duration sessions that this is mostly irrelevant, and ssh, which is probably vulnerable.
The other thing is, the network I administer is not a likely target for denial of services. We're small and have few enemies; *mostly* I have to look out for automated and scripted attacks. Not everyone has this luxury.
> I'm no expert, but wouldn't a security problem with TCP be completely > unrelated to IP?
The problem stems from the fact that certain TCP state is too easy to guess, at least partly because TCP stuff is transmitted in the clear over IP. If you encrypt the traffic at the network (IP) layer, it will help a great deal. (No, I don't know whether IPv6 does this inherently, though of course it could be done with IPv6 just as easily as with IP.)
> The article talks about how the government has been “fortifying” its networks > against this, does that means they quickly rewrote the tcp protocol? I would > love to know.
The article talks about stuff you can do to reduce the risk, by making the vulnerability harder to exploit. For example, reducing the "window" size for acceptable sequence numbers will make the attack harder to perform in proportion to how much you reduce the window. (i.e., if you make the window half as large, the attack is twice as hard.) Making source ports harder to guess also helps a bit. Ideally, encrypting traffic at the network layer (usually IP) is what you ultimately want to do. IPSEC is mentioned.
That's silly. It's used for lost of other things besides baking. In fact, it was the popular use of soda in bathroom toys, an application that has absolutely nothing to do with baking, that lead the dude to mistakenly think there was soda in the pop and incorrectly dub it "soda pop". The truth is, it's not soda that makes it pop but rather carbonation. Soda is also used as a cleaning agent, and sometimes it's also used for its mild alkalinity. Also it's used as an odor absorber and as a whitener. And yeah, in baking, but calling it "baking soda" would be like calling sugar "baking sugar".
screen rocks, but it only works for console and command-line apps. I want to be able to do the same thing with X11 apps. And if I have to restart the X server for some reason, or change the desktop resolution (no, I don't mean zoom like with Ctrl-alt-+, I mean actually change the dimensions of the actual desktop), I don't want to have to close all of my apps.
gdmflexiserver is useful here, but it doesn't solve the fundamental limitations of the current generation of X servers. More work is needed.
> Actually, the GPL is not no-strings. No strings would be public domain.
Yes, this part is true.
> GPL is more like 1 string -- if you release it, provide source.
No, one string would be something like the (current) BSD license (the one string being that you have to credit the original source; with public domain stuff you don't even have to do that). The GPL has additional strings. More than just providing source, you also have to license that source under the GPL -- not just for the software itself but also anything that you link against it. (This is particularly relevant for code libraries, as it prevents them from being adopted by non-GPLed projects. If your goal is to try to talk people into relicensing under the GPL this is a good dynamic, assuming your library is of such quality that the ability to use it is attractive enough to sway anyone's choice of license; if your goal is to make a library that will be useful to as many projects as possible and maybe become a de facto standard, then you want the BSD license instead, or something like it. There is also the LGPL...)
> Depending on your philosophy and whether or not you agree with the GNU > Manifesto, that's either a whisper-thin thread or a big thick rope that > weighs you down.
Yeah, something like that. BSD stuff can be combined and linked with stuff that's under various other licenses, including proprietary licenses; GPLed stuff can't (well, not if you distribute it at all in any way). Depending on whether you agree with RMS, this is either an Important Protection for our Freedom or else it's a restriction that prevents you from using the software in certain situations wherein it would otherwise be useful.
> As a sidenote I might add that Perl 6 will support the functional paradigm.
Perl5 supports *portions* of it already. closures are already fully supported, as well as list-transformation functions. I suppose you meant that Perl6 will widen its support so that it can handle full-blown FP with continuations and the whole works, which matches what I've heard.
> It is just not the only paradigm it will support.
Heckno. Perl will always support contextual programming and imperative programming; object-oriented programming and functional programming are both getting huge boosts in Perl6, and there's talk of logical/declarative paradigm stuff slipping in e.g. from Prolog. Perl is fundamentally a multiparadigmatic language; you can use whichever paradigm is the best fit for the problem space of your program, and you can freely mix and match the paradigms at will, which I do. It's often convenient, for example, to have an object method accept as one of its arguments a coderef (e.g. to use as a callback), which can be a closure. Going the other way, a closure (or a set of related closures) can retain objects and use them to do stuff. I do this stuff today in Perl5. With Perl, you get the best parts of all paradigms. This will be even more true in Perl6, which is getting both real objects *and* continuations, among other things. The support for contextual programming is also being beefed up; a routine will be able to return an object that knows how to return one value in numeric context, another value in string context, and so on. (My personal favourite four-word quote from the Apocalypse series so far is "interesting values of undef". If you don't know why this is awesome, you do not yet fully grok the contextual programming paradigm.)
And yeah, Haskell is more innovative than pragmatic. The innovative things about Perl are three: context, the CPAN, and assimilation. Assimilation in this context means that the Perl dev team actively hunts down other languages and incorporates their nifty features into Perl. There's been a lot of talk about Smalltalk and Haskell on perl6-language, for example. One could argue that another way to say this is, "Perl prefers to let other languages do its innovation for it." But it seems to be a pretty good model. None of the other languages seem to have all of the nifty features that Perl has together in one language.
Context IMO is the most innovative thing about Perl. The CPAN also rocks.
> However, it will be possible for a routine to get Perl5-like semantics for > @_ if that's what it wants.
BTW, I think that will be spelled something like this: sub foo (*@_ is rw) { Subroutine_Code_Goes_Here }
The * flattens any lists or arrays that are passed in, giving you one big list. @_ is what Perl5 called its arglist variable, so I called it that to match what it would be in Perl5; you could call it @args or whatever if you prefer. is rw means read/write, i.e., you can modify it. I could be slightly off on the exact details here, as I'm not certain rw automatically propagates to all the elements in the list; that might have to be stated explicitely another way, I'm not sure. (It's been a while since I read Apocalypse 6, so I'm rusty.)
A syntax shortcut was added in 5.0 so that you don't have to know about the references if all you're doing is $foo[$w][$x][$y][$z] = $bar; it just works. The old Perl4 way of doing things is heavily deprecated and very seldom used.
It is true that multidimensional arrays are implemented using references, but frankly under the hood so are single-dimension arrays. For example, in a subroutine the elements of @_ are actually aliases to the arguments that were passed in. (Now *this* is changing in Perl6, because we're getting real named, typed parameters; the old Perl5 pill-style function prototypes are going away, thankfully. However, it will be possible for a routine to get Perl5-like semantics for @_ if that's what it wants.)
> g++ is probably the slowest compiler I have ever used
C compilers are all terribly slow. I don't know why, but it takes *forever* for a C compiler to compile a medium-sized application; Perl can read the source for an equivalently complex application and start executing in microseconds.
Sure, C runs faster *once it's compiled*... who wants to wait for that? (Yeah, I know, with binary distributions the end users don't have to compile at all, even at install time. But how do C developers tollerate 20-minute compile times every time they tweak the code? It must take weeks to do an hour's worth of debugging!)
> indexing. Its supposed to help it search faster or something like that.
Oh, that, yeah. I'm pretty sure that's not a Linux feature per se but an application that some distros have bundled. I think Mandrake includes it, but I never turned it on.
MacOS 9 has something similar, except that instead of running in the background it ties up the whole system. Fortunately, there's a cancel button, but I have never figured out how to make it not happen at startup, so the user doesn't have to click cancel every morning. (It's probably easy, but my use of the Classic MacOS is pretty much limited to end-user stuff; I mostly avoid that platform when I can. So I'm not very familiar with the administrative type of details like this.)
> "Great in theory, but there's a new Friends episode on Thursday. [...]"
Ewwww. It's too late for this one: brain dammage has already set in, due to too much long-term exposure to television, no doubt.
We lost our TV antenna in a storm in August of 2000 or 2001, and I have never missed it; in fact, if someone in the house suggested getting cable or a new antenna as a way of solving the problem, I would strenuously object; I like things *much* better they way they are now.
Now, if only the VCR would break... then there wouldn't be videos blaring all the time and maybe we could hear ourselves think.
> Other than people citing Kleenex as an example of a lost trademark, I've > never heard anyone refer to a tissue as a Kleenex.
Other than on the internet, I've only one time in my life ever heard anyone call a kleenex a "tissue". I remember it vividly because it took me a long time to figure out what she meant.
Around here (central Ohio), tissue is an art supply, a sort of really thin brightly coloured paper used for children's crafts and stuff, a bit like crepe paper only thinner, and it comes in square or rectangular sheets rather than long skinny rolls. kleenex are things you wipe your nose with. (While we're at it, soda is an ingredient in cookies. No, I'm not going to start calling it "sodium bicarbonate" all the time just so you can call pop "soda"; it's not; there's no soda in it, and there never was. That's carbonation that makes it fizz, not soda. If it fizzed because of soda, it would taste quite utterly nasty.)
The most popular brand of kleenex is Puffs. About one out of every five people actually knows that Kleenex is technically a brand name also, and *nobody* as far as I am aware reserves the term for only referring to that brand (in speech, I mean; in print is another matter, since editors are taught how to cleanse writing of trademarks prior to publication).
As far as I'm aware, Kleenex has not lost their trademark, because they've managed to keep people from using it generically *in print* (or of course in advertising), which seems to be key for trademark law. But it is so much the dominant term in speech that I can't think of a synonym, unless you count the phrase "facial tissue", which nobody actually uses except in situations where they legally can't get away with calling a kleenex a kleenex, such as in print or in advertising.
So, _legally_, Kleenex is a trademark, but informally, it's used as a word.
Jello is in *almost* the same boat, except that Jello has a viable synonym ("gelatin", which is what Jello was short for in the first place). But nobody ever calls it "gelatin" except in print when the editor says they can't call it "jello". Thermos is in _exactly_ the same boat as Kleenex; there's no other word, no suitable synonym for "thermos", so if you're in a situation where you have to avoid the trademark, you end up describing the thing's function or its physical characteristics in order to communicate what sort of thing it is that you're talking about. "I had a Thermos full of soup" becomes "I had an insulated container full of soup in my lunchbox", which is awkward in the extreme. It would be nice if there were a legal precedent for the government to purchase a trademark from a corporation in order to liberate it for the good of everyone, in cases where there's no real synonym. It wouldn't be right to just confiscate the mark (well, not in cases like Kleenex and Thermos where the word was nonsense before the company created the product; Windows and Office are another matter), but the English language could really use the word. With all the tax money we spend on stupid stuff, I'd be quite happy to have the government shell out a couple hundred million to buy the word kleenex out of trademark hock; that would be something genuinely useful, and Kleenex or their parent company or whoever could spend the money advertising a new brand name; a couple hundred million ought to buy quite a strong brand recognition for them, methinks -- stronger than "Kleenex", which is in serious danger of being considered generic by a lot of people.
As far as trademarks that have actually been lost, I don't know, but the legal departments of corporations seem to consider it a real possibility.
I think they're using "database" here to mean RDBMS. Technically a database is just anything that organises data, so a filesystem would count, but that's not how the term is generally used. Usually these days when people say database they mean RDBMS.
The other thing is, most installs is not the only reasonable measure of popularity. I'm pretty sure more people have daily interaction with MySQL than with Berkeley DB directly. Berkeley DB is installed so widely because it's been around longer and because certain key pieces of software depend on or use it for historical reasons, not because people like it better.
Note that I'm not trying to say Berkeley DB is bad or anything, or that MySQL should replace it; they're really quite different things, and they exist for different purposes and fill different niches. I wouldn't consider them to be direct competition really -- well, not mostly. MySQL is in competition with PostgreSQL mainly, and to a lesser extent the major commercial database offerings (Oracle, MS SQL Server) and various lesser-known projects (e.g. Firebird SQL). Berkeley DB competes with I think certain Gnu libraries and maybe some other things I'm even less aware of. Not that MySQL and Berkeley DB are in _completely_ different worlds; they both might reasonably be said to compete on some level with SQLite for example, so there is some overlap between their areas of application. But still, they're mostly not really in the same category.
Sure, they're both databases. But to say one is more popular than the other is like arguing whether traceroute is more popular than Mozilla. They are, after all, both internet software.
> Is there any kind of objective review of these two ? > I'm trying to decide on one to distribute locally.
For what purpose? Debian is probably better for production servers, but Mandrake makes a good desktop system. Either, of course, will do in either situation, but those are their relative strengths IMO.
> What I don't understand about the OE exploit is that it basically results > from running HTML code in something called a Local Security Zone of IE.
There's a lot of technical mumbo jumbo, but the long and short of it is, OE takes whatever data anybody sends you by email and mostly trusts it. Normal mail clients don't trust the data at *all*; they just store and display it. If you want to see an excellent example of a user-friendly mailreader that gets this right, try Pegasus Mail. It's freeware, it's pretty featureful, and if you want to use it to catch a virus, you have to jump through hoops. (Specifically, you have to click on Attachments, select the executable virus attachment, click the Save button; a dialog box pops up with the word VIRUS in the title and a big nasty exclamation point, warning that the attachment is executable and could be a virus. You have to click Okay (the default is Cancel), and then a normal Save As dialog comes up, so you can pick where to save it and (if desired) change the filename. Then you have to open the folder where you saved it and double click on the executable file that you saved.)
You only have to jump through this type of hoops for executable stuff. Images and HTML are displayed inline (although you can turn these features off in the options if desired).
Slashdot Mirror
> Is reference counting really that bad?
Refcounting can't collect everything if you have any circular references. It's
what Perl5 has, and we live with it, but Perl6 is getting real garbage
collection (mark-and-sweep I think, or at any rate something more advanced
than refcounting).
> I think with hindsight one really has to admit that "certain people" were
> absolutely right,
To say that for sure, I'd have to know more than I do about the details of the
licensing of Qt at the time. All I really know is that RMS didn't consider
it free enough; that in itself doesn't mean for sure to me that it was
unsuitable; it raises questions, but that's all; there are things that are
plenty free enough for me but not for RMS. Game software like D1X and D2X
and njudge that are open-source (in the sense that you can make and distribute
changed versions under the same terms under which you received it) but are
licensed for non-commercial use only (who needs to use a game commercially?),
software licensed in a way that allows only the original author to link it
against proprietary extensions (but anyone can distribute it without doing
so, just as with GPLed software), and frankly sometimes I wonder whether
RMS really thinks the BSD license is quite free enough.
Like I said, I don't know the details of the old Qt license, so I don't know
whether it was free enough for me; maybe it wasn't, I don't know. (I also
don't have a vested personal interest in finding out, since it's historical
now anyway and also because the KDE panel doesn't have drawers, which are
an essential feature for me, which is why I use Gnome.) I only know that
it wasn't free enough for RMS. (And that there were some who agreed with
him, as of course there always are; hence, "certain people" in the plural.)
And frankly, it wasn't important to my post either. As far as being a reason
why Gnome was started and was based on GTK instead, the fact that it wasn't
free enough for RMS was really enough. It isn't really significant whether
he was right about that, in terms of the effect that his stance had on the
subsequent developments I discussed.
So that's why I only said what I said, and didn't elaborate.
Hey, whaddayaknow, that's ten.
> One is a complete Microsoft fanatic, and the other is a totally rabid
> anti-MS Linux & BSD fanatic. Thet get along great at work
Of course they get along great -- each one does all the work the other one
doesn't want to get stuck with. The Linux/BSD guy never has to touch regedit,
and the MS guy never has to edit a config file. Good arrangement.
> I doubt many employers want a mediocre jack-of-all-trades kind of guy.
Think: small employers. Look for employers with 10-50 employees _total_,
and you'll find the places that want a TCG[1]. They only hire 0-2 IT guys
each, but there are a lot of these places, so in theory there are quite a
few TCG positions available. The problem is, of course, that right now most
of the people who already have these jobs aren't quitting to move onto greener
pastures elsewhere, because jobs are hard to find. (I, for example, am right
now holding onto my TCG position for dear life, even though when I took it in
2000 my goal was to keep the job for "at least two years", put it on my
resume, and look for something more advanced.) But that's true for people
with a more focused skillset, too; IT jobs in general are scarce right now.
(Heck, around here just about any kind of white-collar job is currently
seeming quite a lot like a hen's tooth, although it's not quite as bad as it
was about a year ago or so, and the blue-collar sector has picked up quite
a bit already, which is a positive omen.)
[1] The Computer Guy -- i.e., one-man IT department. The official job title
and job position vary greatly, but in practice your basic job position is
"do all the computer stuff". You'll help other staff when they don't
know how to get an attachment or copy and paste something; you'll unstick
printers; you'll set up and administer databases and web servers and
maybe mail servers; you'll purchase and install new computer and network
equipment, assign IP numbers, and coordinate with the overall boss to
develop IT policy. You'll make the phone calls and fill out the RMAs
when things go bad under warrantee, and when things aren't under warantee
you'll figure out exactly what parts you need, get a purchase order from
the accounting person, order the parts, and install them. You'll change
screensavers and rotate wallpaper. You'll upgrade software, help
determine hardware upgrade cycles (in terms of timespan), and when it's
time to do hardware upgrades you'll pick out the new stuff, order it, and
install it when it arrives. You'll look stuff up on the internet for
staff who weren't able to find it, and you'll create and print documents
for staff who aren't comfortable doing that. Occasionally you'll get
stuck with data entry. If they discover that you can do digital
photography and desktop publishing, you'll end up doing that too.
You'll find tactful ways to explain PEBCAK errors without making people
feel stupid, and you'll change toner cartridges, write backup scripts
and arrange for them to run regularly, write other scripts to do various
other convenient things. You'll create custom reports, and you'll write
scripts that generate a given report automatically. Basically, if it
involves a computer and someone doesn't feel comfortable doing it, it
becomes your job. If you do a good job and don't make people feel stupid,
the other staff will think you're wonderful.
> there's got to be a reason why KDE developers chose to write their own
> from scratch rather than integrate Gecko.
Mozilla wasn't really ready for primetime yet when they started working on
Konqueror, and there was some doubt in some circles whether it ever would be.
If they were starting Konqueror from scratch now, they probably would embed
Gecko rather than creating KHTML, which would put Konqueror in the same
category as Galeon and Chimera. On the other hand, if Gnome and Gimp were
starting now they might've used Qt (or, indeed, might not have been started
at all, if KDE already existed), but at the time Qt wasn't Free enough to
suit certain people -- hence, GTK and Gnome. (It would be nice if a theme
selection/creation/application engine existed that themed both of them
together -- preferably it should theme both Gnome1 and Gnome2 applications
as well as KDE ones. And other kinds of integration, like supporting one
another's panel apps and whatnot, is good too.)
Personally, I'm glad we have both Gnome and KDE and that they're different,
because I like having more than one good choice. (Yeah, there are other
choices; some of them are even almost featureful...) A certain amount of
duplication of effort is good, because it creates choice. It is possible
to go too far, though, and if all the browsers you mention were complete
duplication of effort that would be bad. As it happens, though, there are
basically two OSS graphical browser layout engines (that matter): Gecko,
and KHTML. Almost all of the browsers use one or the other, so that cuts
down quite a bit on the duplication of effort. Yeah, there's duplication
in the front-end interface stuff (toolbars and whatnot), but at least they're
not reinventing the whole browser layout engine.
> They swim with their wings.
Actually, if you've ever watched them, its tempting to say that they pretty
much *do* fly, only they do it in the water instead of the air.
SYN floods can be rendered mostly ineffective. Google for "syn cookies" or
read Steve Gibson's writeups on DDOS attacks. ACK floods (reflection attacks)
are a somewhat larger problem, because they work by consuming bandwidth. The
two main ways to protect against those are by filtering ACK packets (which only
works for systems that don't need to initiate connections) or by getting a new
IP address any time it happens (presumably via DHCP). The former is untenable
for client systems, and the latter is mostly untenable for servers. (A system
that needs to be both a client and a server could be very hard to protect.)
This RST attack is interesting; I wouldn't want to be ignorant of it, certainly,
given that part of my job is network administration. I don't administer any
routers or domain servers, however; I deal mostly with http, which tends to
use such short-duration sessions that this is mostly irrelevant, and ssh,
which is probably vulnerable.
The other thing is, the network I administer is not a likely target for denial
of services. We're small and have few enemies; *mostly* I have to look out
for automated and scripted attacks. Not everyone has this luxury.
> I'm no expert, but wouldn't a security problem with TCP be completely
> unrelated to IP?
The problem stems from the fact that certain TCP state is too easy to guess,
at least partly because TCP stuff is transmitted in the clear over IP. If
you encrypt the traffic at the network (IP) layer, it will help a great deal.
(No, I don't know whether IPv6 does this inherently, though of course it could
be done with IPv6 just as easily as with IP.)
> The article talks about how the government has been “fortifying” its networks
> against this, does that means they quickly rewrote the tcp protocol? I would
> love to know.
The article talks about stuff you can do to reduce the risk, by making the
vulnerability harder to exploit. For example, reducing the "window" size for
acceptable sequence numbers will make the attack harder to perform in
proportion to how much you reduce the window. (i.e., if you make the window
half as large, the attack is twice as hard.) Making source ports harder to
guess also helps a bit. Ideally, encrypting traffic at the network layer
(usually IP) is what you ultimately want to do. IPSEC is mentioned.
> Sure there is: "Dewar."
Never heard of it.
> You can call it "baking soda,"
That's silly. It's used for lost of other things besides baking. In fact,
it was the popular use of soda in bathroom toys, an application that has
absolutely nothing to do with baking, that lead the dude to mistakenly think
there was soda in the pop and incorrectly dub it "soda pop". The truth is,
it's not soda that makes it pop but rather carbonation. Soda is also used
as a cleaning agent, and sometimes it's also used for its mild alkalinity.
Also it's used as an odor absorber and as a whitener. And yeah, in baking,
but calling it "baking soda" would be like calling sugar "baking sugar".
> You can easily do this if you use screen.
screen rocks, but it only works for console and command-line apps. I want to
be able to do the same thing with X11 apps. And if I have to restart the X
server for some reason, or change the desktop resolution (no, I don't mean
zoom like with Ctrl-alt-+, I mean actually change the dimensions of the actual
desktop), I don't want to have to close all of my apps.
gdmflexiserver is useful here, but it doesn't solve the fundamental limitations
of the current generation of X servers. More work is needed.
> Actually, the GPL is not no-strings. No strings would be public domain.
Yes, this part is true.
> GPL is more like 1 string -- if you release it, provide source.
No, one string would be something like the (current) BSD license (the one
string being that you have to credit the original source; with public domain
stuff you don't even have to do that). The GPL has additional strings. More
than just providing source, you also have to license that source under the
GPL -- not just for the software itself but also anything that you link
against it. (This is particularly relevant for code libraries, as it
prevents them from being adopted by non-GPLed projects. If your goal is
to try to talk people into relicensing under the GPL this is a good dynamic,
assuming your library is of such quality that the ability to use it is
attractive enough to sway anyone's choice of license; if your goal is to
make a library that will be useful to as many projects as possible and maybe
become a de facto standard, then you want the BSD license instead, or
something like it. There is also the LGPL...)
> Depending on your philosophy and whether or not you agree with the GNU
> Manifesto, that's either a whisper-thin thread or a big thick rope that
> weighs you down.
Yeah, something like that. BSD stuff can be combined and linked with stuff
that's under various other licenses, including proprietary licenses; GPLed
stuff can't (well, not if you distribute it at all in any way). Depending
on whether you agree with RMS, this is either an Important Protection for
our Freedom or else it's a restriction that prevents you from using the
software in certain situations wherein it would otherwise be useful.
> As a sidenote I might add that Perl 6 will support the functional paradigm.
Perl5 supports *portions* of it already. closures are already fully supported,
as well as list-transformation functions. I suppose you meant that Perl6 will
widen its support so that it can handle full-blown FP with continuations and
the whole works, which matches what I've heard.
> It is just not the only paradigm it will support.
Heckno. Perl will always support contextual programming and imperative
programming; object-oriented programming and functional programming are
both getting huge boosts in Perl6, and there's talk of logical/declarative
paradigm stuff slipping in e.g. from Prolog. Perl is fundamentally a
multiparadigmatic language; you can use whichever paradigm is the best fit
for the problem space of your program, and you can freely mix and match the
paradigms at will, which I do. It's often convenient, for example, to have
an object method accept as one of its arguments a coderef (e.g. to use as
a callback), which can be a closure. Going the other way, a closure (or a
set of related closures) can retain objects and use them to do stuff. I
do this stuff today in Perl5. With Perl, you get the best parts of all
paradigms. This will be even more true in Perl6, which is getting both
real objects *and* continuations, among other things. The support for
contextual programming is also being beefed up; a routine will be able to
return an object that knows how to return one value in numeric context,
another value in string context, and so on. (My personal favourite
four-word quote from the Apocalypse series so far is "interesting values
of undef". If you don't know why this is awesome, you do not yet fully
grok the contextual programming paradigm.)
And yeah, Haskell is more innovative than pragmatic. The innovative things
about Perl are three: context, the CPAN, and assimilation. Assimilation
in this context means that the Perl dev team actively hunts down other
languages and incorporates their nifty features into Perl. There's been a
lot of talk about Smalltalk and Haskell on perl6-language, for example.
One could argue that another way to say this is, "Perl prefers to let other
languages do its innovation for it." But it seems to be a pretty good model.
None of the other languages seem to have all of the nifty features that Perl
has together in one language.
Context IMO is the most innovative thing about Perl. The CPAN also rocks.
> However, it will be possible for a routine to get Perl5-like semantics for
> @_ if that's what it wants.
BTW, I think that will be spelled something like this:
sub foo (*@_ is rw) { Subroutine_Code_Goes_Here }
The * flattens any lists or arrays that are passed in, giving you one big list.
@_ is what Perl5 called its arglist variable, so I called it that to match
what it would be in Perl5; you could call it @args or whatever if you prefer.
is rw means read/write, i.e., you can modify it. I could be slightly off on
the exact details here, as I'm not certain rw automatically propagates to all
the elements in the list; that might have to be stated explicitely another way,
I'm not sure. (It's been a while since I read Apocalypse 6, so I'm rusty.)
A syntax shortcut was added in 5.0 so that you don't have to know about the
references if all you're doing is $foo[$w][$x][$y][$z] = $bar; it just works.
The old Perl4 way of doing things is heavily deprecated and very seldom used.
It is true that multidimensional arrays are implemented using references,
but frankly under the hood so are single-dimension arrays. For example,
in a subroutine the elements of @_ are actually aliases to the arguments
that were passed in. (Now *this* is changing in Perl6, because we're
getting real named, typed parameters; the old Perl5 pill-style function
prototypes are going away, thankfully. However, it will be possible for
a routine to get Perl5-like semantics for @_ if that's what it wants.)
> g++ is probably the slowest compiler I have ever used
C compilers are all terribly slow. I don't know why, but it takes *forever*
for a C compiler to compile a medium-sized application; Perl can read the
source for an equivalently complex application and start executing in
microseconds.
Sure, C runs faster *once it's compiled*... who wants to wait for that?
(Yeah, I know, with binary distributions the end users don't have to compile
at all, even at install time. But how do C developers tollerate 20-minute
compile times every time they tweak the code? It must take weeks to do an
hour's worth of debugging!)
> indexing. Its supposed to help it search faster or something like that.
Oh, that, yeah. I'm pretty sure that's not a Linux feature per se but an
application that some distros have bundled. I think Mandrake includes it,
but I never turned it on.
MacOS 9 has something similar, except that instead of running in the background
it ties up the whole system. Fortunately, there's a cancel button, but I have
never figured out how to make it not happen at startup, so the user doesn't
have to click cancel every morning. (It's probably easy, but my use of the
Classic MacOS is pretty much limited to end-user stuff; I mostly avoid that
platform when I can. So I'm not very familiar with the administrative type
of details like this.)
> "Great in theory, but there's a new Friends episode on Thursday. [...]"
Ewwww. It's too late for this one: brain dammage has already set in, due to
too much long-term exposure to television, no doubt.
We lost our TV antenna in a storm in August of 2000 or 2001, and I have never
missed it; in fact, if someone in the house suggested getting cable or a new
antenna as a way of solving the problem, I would strenuously object; I like
things *much* better they way they are now.
Now, if only the VCR would break... then there wouldn't be videos blaring all
the time and maybe we could hear ourselves think.
> Other than people citing Kleenex as an example of a lost trademark, I've
> never heard anyone refer to a tissue as a Kleenex.
Other than on the internet, I've only one time in my life ever heard anyone
call a kleenex a "tissue". I remember it vividly because it took me a long
time to figure out what she meant.
Around here (central Ohio), tissue is an art supply, a sort of really thin
brightly coloured paper used for children's crafts and stuff, a bit like
crepe paper only thinner, and it comes in square or rectangular sheets rather
than long skinny rolls. kleenex are things you wipe your nose with. (While
we're at it, soda is an ingredient in cookies. No, I'm not going to start
calling it "sodium bicarbonate" all the time just so you can call pop "soda";
it's not; there's no soda in it, and there never was. That's carbonation
that makes it fizz, not soda. If it fizzed because of soda, it would taste
quite utterly nasty.)
The most popular brand of kleenex is Puffs. About one out of every five
people actually knows that Kleenex is technically a brand name also, and
*nobody* as far as I am aware reserves the term for only referring to that
brand (in speech, I mean; in print is another matter, since editors are
taught how to cleanse writing of trademarks prior to publication).
As far as I'm aware, Kleenex has not lost their trademark, because they've
managed to keep people from using it generically *in print* (or of course
in advertising), which seems to be key for trademark law. But it is so
much the dominant term in speech that I can't think of a synonym, unless
you count the phrase "facial tissue", which nobody actually uses except in
situations where they legally can't get away with calling a kleenex a kleenex,
such as in print or in advertising.
So, _legally_, Kleenex is a trademark, but informally, it's used as a word.
Jello is in *almost* the same boat, except that Jello has a viable synonym
("gelatin", which is what Jello was short for in the first place). But
nobody ever calls it "gelatin" except in print when the editor says they
can't call it "jello". Thermos is in _exactly_ the same boat as Kleenex;
there's no other word, no suitable synonym for "thermos", so if you're in
a situation where you have to avoid the trademark, you end up describing
the thing's function or its physical characteristics in order to communicate
what sort of thing it is that you're talking about. "I had a Thermos full
of soup" becomes "I had an insulated container full of soup in my lunchbox",
which is awkward in the extreme. It would be nice if there were a legal
precedent for the government to purchase a trademark from a corporation in
order to liberate it for the good of everyone, in cases where there's no
real synonym. It wouldn't be right to just confiscate the mark (well, not
in cases like Kleenex and Thermos where the word was nonsense before the
company created the product; Windows and Office are another matter), but
the English language could really use the word. With all the tax money
we spend on stupid stuff, I'd be quite happy to have the government shell
out a couple hundred million to buy the word kleenex out of trademark hock;
that would be something genuinely useful, and Kleenex or their parent
company or whoever could spend the money advertising a new brand name;
a couple hundred million ought to buy quite a strong brand recognition
for them, methinks -- stronger than "Kleenex", which is in serious danger
of being considered generic by a lot of people.
As far as trademarks that have actually been lost, I don't know, but the
legal departments of corporations seem to consider it a real possibility.
> Personally the idea of using a chemical as a coolant doesn't put me at ease...
...) are
What was it you planned on using as a coolant then, vacuum?
The most popular coolants (motor oil, water, tropospheric vapour,
all made of chemicals.
I think they're using "database" here to mean RDBMS. Technically a database is
just anything that organises data, so a filesystem would count, but that's not
how the term is generally used. Usually these days when people say database
they mean RDBMS.
The other thing is, most installs is not the only reasonable measure of
popularity. I'm pretty sure more people have daily interaction with MySQL
than with Berkeley DB directly. Berkeley DB is installed so widely because
it's been around longer and because certain key pieces of software depend
on or use it for historical reasons, not because people like it better.
Note that I'm not trying to say Berkeley DB is bad or anything, or that MySQL
should replace it; they're really quite different things, and they exist for
different purposes and fill different niches. I wouldn't consider them to be
direct competition really -- well, not mostly. MySQL is in competition with
PostgreSQL mainly, and to a lesser extent the major commercial database
offerings (Oracle, MS SQL Server) and various lesser-known projects (e.g.
Firebird SQL). Berkeley DB competes with I think certain Gnu libraries and
maybe some other things I'm even less aware of. Not that MySQL and Berkeley
DB are in _completely_ different worlds; they both might reasonably be said
to compete on some level with SQLite for example, so there is some overlap
between their areas of application. But still, they're mostly not really in
the same category.
Sure, they're both databases. But to say one is more popular than the other
is like arguing whether traceroute is more popular than Mozilla. They are,
after all, both internet software.
> Is there any kind of objective review of these two ?
> I'm trying to decide on one to distribute locally.
For what purpose? Debian is probably better for production servers, but
Mandrake makes a good desktop system. Either, of course, will do in either
situation, but those are their relative strengths IMO.
> What I don't understand about the OE exploit is that it basically results
> from running HTML code in something called a Local Security Zone of IE.
There's a lot of technical mumbo jumbo, but the long and short of it is, OE
takes whatever data anybody sends you by email and mostly trusts it. Normal
mail clients don't trust the data at *all*; they just store and display it.
If you want to see an excellent example of a user-friendly mailreader that
gets this right, try Pegasus Mail. It's freeware, it's pretty featureful,
and if you want to use it to catch a virus, you have to jump through hoops.
(Specifically, you have to click on Attachments, select the executable virus
attachment, click the Save button; a dialog box pops up with the word VIRUS
in the title and a big nasty exclamation point, warning that the attachment
is executable and could be a virus. You have to click Okay (the default is
Cancel), and then a normal Save As dialog comes up, so you can pick where to
save it and (if desired) change the filename. Then you have to open the
folder where you saved it and double click on the executable file that you
saved.)
You only have to jump through this type of hoops for executable stuff.
Images and HTML are displayed inline (although you can turn these features
off in the options if desired).
> We need internet licenses. Nobody without a geek code should be granted an
:-)
> IP address. It's that simple.
No, I think we should give everyone an IP address, and just make them
calculate their own subnet mask