DFly will remain relevant for having a pretty relaxed but surprisingly stable development model. While there were still bugs that kept me from using it as a gateway (and software support problems that kept me from using it as a desktop), it never actually crashed or did anything harmful - it just couldn't route packets the way they should be routed - and nobody replied to my message on bugs@ or the IRC channel. I switched to NetBSD 3.0-beta and the same configs (for PF and inetd) worked. So I stuck with that. None of the same ACPI weirdness either.
FreeBSD 5 on the same machine could do almost nothing right at all, so I gave that up. I'm waiting for 5.4 release to make an assessment, because I didn't even get a chance to fetch sources this time.
Out of curiosty, has the new shutdown sync hack been resolved? From 5.3 and a while after, it wold take ages to sync disks, since buffers could be created anew even after shutdown - only three consecutive "nothing left" instances would finalise the syncing. This is unlike what every other OS does (since they don't generate new buffers after shutting everything down) so I'm guessing 5.3 introduced some bugs that needed this hack. So, is that over now or do we still have long-ass shutdowns?
The 'unofficial roadmap' you can find (http://www.feyrer.de/NetBSD/roadmap.html). For 3.0, some things are already in-tree for it (PF, PAM), but most of that hasn't even shown evidence of being attempted. I'm not sure which devs actually agree with that map, but it is clear to see they don't all believe they can do it. 3.0-beta currently offers very little 2.0 doesn't for a huge range of users, the most likely to be noticed being the wonderful PF (which is forwarding these packets now... and normalizing them!).
One note to PF newbies, if you want behavior like the other packet filters (linear top->bottom checking of rules, stopping at any matches), use 'quick' for every rule. It will save you headaches figuring out why some rules appear to be completely useless.
Back on topic, it appears NetBSD (or at least someone there) decided to use Solaris-like SMP locking (the same thing that 'killed' FreeBSD 5). We'll see how that pans out, or if it's even true: but suffice to say it's not there in the netbsd-3 branch yet.
I don't think you know what I mean at all. I didn't deny any of that. I am refuting that its (accused) move to replace Linux is not hampering its quality (where 'quality' is 'does what it's supposed to properly', not 'does what Linux does', which is a stupid argument).
Do you know why I dropped Linux on my gateway? It couldn't handle IPSec properly. On certain protocols (yes, it actually had protocol-specific bugs, even though IPSec is meant to be protocol agnostic) it would just drop packets without any clue as to what was happening. The exact same configurations on DragonFly and NetBSD worked exactly as expected. THAT is what I am talking about when I say quality. If a BSD says something will work in a stable branch, it will work. This is not the case in Linux. 2.6 is meant to be a stable branch, yet a lot of things either don't work or have huge debilitating bugs like this IPSec misfeature. I don't care if Linux' performance runs loops around NetBSD, if it doesn't do what it's supposed to and has no practical workarounds, THIS FAR INTO A STABLE BRANCH, it is not even worth considering.
And since NetBSD is gaining ground (albeit slowly) to be able to replace Linux installs for more and more applications, all the better. Others, too, will be able to replace Linux with a system that Works Properly All The Time, not just Works Properly in 2.6.8-rc3-mm2-bbq5.
FreeBSD 5.x is free but not very fast, and while this will improve over time, the bugginess and complexity in the meantime isn't worth it for most.
NetBSD got much faster in 2.0. It can now compete with FreeBSD 4 in UP, and can run a not-bad SMP (if you know what you're doing, that is).
OpenBSD is useful, because it doesn't stop you from running a text editor - in this case vi. That's a lot better than the 'default install' of a lot of Linux distributions I know.
The problem is that even the loopback interface can be sniffed on (usually only by root, admittedly, but still) so any authentication happening with sockets is going to be a bit on the dangerous side. Libraries are still in the protected address space of their host process, so there's no problem. I like daemons, don't get me wrong, but I wouldn't trust one to handle authentication - especially since there's no real advantage to it.
Now, if we were talking about network authentication with decent SSL or other encryption between daemon and client, that I could agree with. But I believe that's already been done in other ways...
Is that really what bothers you? I have to report that in spite of the PAM inclusion, NetBSD 3.0-beta is still a world of performance and efficiency, and EVERYTHING works properly. Things that always broke on Linux 2.6.11, for instance.
It's good that it's moving to be able to replace Linux, that means it can gain market share while still retaining its quality. What the hell is wrong with you? If implementing features of questionable design (even though the implementation, Open PAM, is about as good as you can get) kills an OS for you, you are going to have to ignore FreeBSD (why? because it has made nothing but bad design decisions lately, AND IT HAS THE SAME PAM IMPLEMENTATION) and Linux (one big bad design flaw, and it's the corporate monster you're afraid NetBSD will be).
NetBSD is probably the only system that is moving to corporate-worthy and Linux-replacing changes, while not actually losing any quality in the process. Yes the source tree is a bit bigger now. But yes it is also now more appealing to a large number of users who were previously stuck with Linux or FreeBSD so as to have a base-system PAM. If it increases market share without decreasing quality, it's a Good Thing. Linux does it almost every day, and Linux often does decrease quality.
Would Linux 2.6 be where it is if it had been conservatively developed on from 2.4? Short answer: No. Long answer: Definitely not.
Branching lets people use a continuing product with one development model while another version of the same product is worked on with another development model. After a certain agreed-upon stage of development, the roles change. For instance, the unstable branch gets to a stage of maturity, and it is made the stable branch.
That's why BSDs always have something stable and typically something getting new tech, and are going exactly where they should be. Meanwhile Linux has unbelievable numbers of bugs (Coverity alone found almost 1000 in 2.6.8, and 5 in NetBSD -current) and constant ABI incompatibilities - NPTL changes, IPSec changes, changes that mean old NVidia video drivers don't work any more, and so on. Why? No good reason. And it's all done in a 'stable' branch because Linus doesn't see a need to fork right now. So people are actually using an active development branch that is labelled a stable branch, and are surprised when something breaks or requires rebuilding significant userland components.
When Windows can use algorithms other than DES and 3DES for IPSec, then we'll talk. And where are the static keys? It wouldn't be so bad if its twisted way of setting up key exchanges was workable, but it's only barely so. And IPSec, if you'd ever used it properly, you would know to be a VERY valuable security and privacy feature, yet in Windows it's on barely workable levels. Linux got a not-too-bad IPSec in kernel 2.6, and while it's still a lot flakier than any BSD (like having to use -m tunnel), it actually works and can use algorithms that aren't yet obsolete. And it can use them properly. Static keys, IKE, tunnel, transport, whatever, it works. Windows is excruciating and crippled in this respect, and it's a huge lacking in its security capabilities.
That's why many *nix's don't need to make huge progress: they're already on the bleeding edge. With Windows so far behind in respects like these, it need all the improvement it can get.
Wrong. They would have to modify it, and hence release the sources (as per GPL). Since there are no sources and no admitting they did so, none of those products have Linux. On the other hand, it does have things from NetBSD in hardware and software (see http://www.feyrer.de/NetBSD/blog.html - search 'PS2' (gets you an XIII-related piece) and 'Playstation' (the latter being the PSP itself). I say this because linking to these from Slash seems to break.
I guess I should ask you, is blind zealous ignorance bliss?
'make install clean' does the same thing but without re-forking and with any caches make could have had (which most cleans won't need, admittedly). Learning about make's behavior is highly recommended: don't be like the 90% of stupid guides and tutorials I've seen which insist on using && to do the same thing with more overhead and typing.
An extra bonus is that arguments persist for all arguments to a make, for instance:
make -j3 -DDEBUG depend all install clean (all targets get -j3 and -DDEBUG)
make -j3 -DDEBUG depend && make all (and so on - only first target gets those flags, and repeating them all is highly impractical).
This has been a public service announcement by someone with a clue.
You would still only have the same static perspective, so even skewing won't 'create' things you would see from a different perspective (hard to explain but you should already know what I mean).
Even Active Camouflage uses a similarly flawed approach, in that it doesn't look behind it, but uses a static 'before' image that a 'monitor' mapped on an arbitrary surface (e.g. the trenchcoat) does its best to display. It's a neat party trick but it doesn't allow changing perspective or anything else useful like that. But, when we have a sensor surface and a monitor surface (with enough colours) AND a real time processor capable of compensating for the differences, and possible lighting issues on both sides, then we would have it.. then all it takes is to merge the sensing and monitoring into one surface. That's the ideal goal, I'm sure, since it's the only way to get anywhere near believable transparency. Maybe a decade off, but maybe less too - never underestimate research grants and caffeine.
I personally don't think that having graphics that don't differ enough from other games is going to water down the game itself. Wind Waker made a huge step in the right direction by taking a risk with Cel Shading, which was very successful according to just about everyone who's actually played it. It looks great and the graphics won't get out-dated quickly because the style has survived in cartoons for decades. The step to realism adds the risk of becoming dated (since something else can be 'more' realistic) but on the other hand it also appeals to a different audience. And, fancy that, life is life. If every game was perfectly realistic, of course they'd all look the same!
Besides that, the 3D Zeldas (at least OoT) did not look at all like their early development snapshots... like the early OoT that looked like Mario 64 with a sword. This game might take new directions (if there's still time) that will still make it unique, and if not, there'll always be the good gameplay and everything else that IS unique to the Zelda experience.
Innovation has always been a Zelda trademark: after the transition to 3D in OoT, MM completely changed how Zeldas were structured (essentially in putting much more focus into optional quests, and the time looping system) which lead to much more interesting game play, and then Wind Waker changed how Zelda WORLDS were structured, and completely took out the idea that your abilities in combat should be limited - as long as you know what you're doing you can pull off unbelievable BS in battles and get out unscathed. Gameplay innovation is always a Zelda thing and I would have to say it's accelerating, at least in the 3D ones (I can't speak for Oracle* and Minish Cap). So no amount of graphic lameness can kill what an awesome game this next one will be, if the trend is to be followed.
It's nice that your country supports free speech, isn't it? You could show your love for your freedoms by actually making good use of them, and posting things that actually make sense or, I know this sounds crazy, have some factual or logical basis. Spelling is nice too, but don't feel it's somehow more important than knowing what you're talking about.
Theo was asking for the documentation on behalf of the whole FOSS OS community, but he just happens to be among the only people with the balls to actually speak up and make a difference. OpenBSD may be the first to benefit from the documentation, or it may not, it doesn't really matter. If Adaptec wants to be taken seriously by the large number of FOSS OS users, it's going to have to actually at least provide documentation to developers and the community so that the software support for their hardware is good. I talked about this before: to a *nix user, support for the hardware they will buy comes FIRST, THEN come quality, availability and cost (in an order depending on the user). No sane admin would buy hardware he knows won't work or will work so shoddily under his OS Of Choice that it's not worth its extra 'value'.
Using binary junk, already impossible to 'use with some modifications', is not proper software support. Using drivers made through assumption rather than documentation is also risky business. Adaptec only have to release the documentation for their hardware to merit a lot more respect from the community, which translates into more purchases. Nobody can possibly argue this. Now, they may have their reasons for withholding the documentation, and it is their right; but it's up to them to decide if they want to risk losing sales (and they will) for their pride or whatever they're protecting. It is a public opinion that they are choosing wrong.
(This is from someone with some boobie experience)
You're the idiot, and it's in not realising that while calling GNU/Linux just 'Linux' is just fine, calling KDE/GNOME/etc 'Linux' is idiocy. It runs just as well on any BSD, and other platforms too I've heard. Yet the same icons are still there, and are drawn the same. Therefore the icons have NOTHING to do with Linux, except that you can get them drawn on a Linux box. The same way, you can take the images and stick them on a Windows box, within resolution limits. Now, they we're MADE for the Windows system of course, they were for their desktop environment or window manager, but they weren't made for Linux either - for all you know it could have been made under a BSD.
I keep getting asked about my WindowMaker environment, "so is that Linux?", and I have to explain that, no it's not, it's WindowMaker in an XOrg server, but yes the kernel is Linux, not that it matters here since its effects on my graphical interface are completely trivial. Of course this is usually asked by the people who think that there are only three systems out there (MacOS, Windows, and Linux - and that all of them only run on x86 because there is no other architecture, and what's an architecture?), and so on.
But you're not much better. Classing OS-agnostic software like KDE or GNOME as Linux just because it happens to be MOST OFTEN USED in Linux, and saying that separating kernel from software is self masturbation and completely pointless, is idiocy of the highest order. Hell, the ICONS, which are completely untied to the kernel, definitely shouldn't be stuck with the OS title.
Even if OpenBSD DID matter very little (hint: this is not the case), releasing the documentation means everyone gets better drivers (reiterate: better. Documentation is better than assumption) and good management tools. People want to buy hardware to run Linux, *BSD, whatever on, and if the support is good (even if it's just documentation!) the product is good.
Look at the Ti wireless chipset versus the offerings of Prism*. The Ti chipset is cheap to manufacture and very popular now, yes it sucks hard but it works well enough for most - but because its support is close to none (and if you say "but acx100 exists!", you obviously haven't tried it...), buying it is a very bad move. If documentation was released, solid drivers could be written and the hardware would suddenly become worth buying for a HUGE number of users - and this would be fair because the chipset is now in (no kidding) the majority of commercial wireless cards here in Australia and who knows where else.
God forbid a developer and a major contributor to our freedoms should be upset that a corporation has held off releasing documentation after months of 'negotiation'. He may chew people out on mailing lists, but that does not make an asshole. His way of dealing with people personally might just be a little intolerant, but he has done much more for the open source community than any other single leader - and he does NOT need to sit on a huge platform of sponsorship and hype to make a difference. What did Linus do? Write a kernel with a license that corporations decided was good in fighting the Microsoft monopoly. Bam, it's done. Theo actually swam upstream with little help and brought a good project with good ideals which DO help others - OpenSSH being everyone's favorite example. Where would you be without it? Up sh!t creek.
If you don't use OpenBSD because of its project leader, you may as well never use or communicate with any OpenSSH clients or servers and you can forget about PF. Just to be a real self righteous prick you may as well not use the internet at all just in case your packets pass through a server which an 'asshole' contributed to. Or a hardware design. In fact, how do you know assholes didn't grow the trees that maintain your oxygen supply? May as well stop breathing.
How it is a serious drawback? It's the point of the BSD license; maximal freedom while retaining copyright. It's why (see http://www.feyrer.de/NetBSD/blog.html ) NetBSD is used in countless embedded devices silently, in contrast with Linux which requires re-releasing changes made and announcing that they're using it.
You said that the problem with the BSD license is that it isn't a clone of the GPL, which implies you're a GPL nazi, and as a wonderful side note you completely missed the point of the article and thread.
Theo's complaining that there is no documentation with which to write properly open management tools and improve existing drivers, and so on. This has NOTHING to do with the BSD license. BSD projects can (and do) include GPL source in the base systems, but they prefer not to. It wouldn't matter what license they had in this case, because if you look closely, there's no documentation being released to Linux developers either - but they don't seem to mind because they only care if it works, not how well or securely or whatever.
So, yes, you have no idea what you're talking about and should probably read the article and the different licenses (just for clarity), before someone with less restraint than me responds to your posts.
Are you kidding? In the early days (pre-2.4 Linux) Adaptec wrote SCSI drivers for FreeBSD because it had the GOOD SCSI subsystem and then ported them to Linux when they had the time. FreeBSD's were still more solid just because of the system itself being solid, and being the first to get support helped too.
The situation hasn't really changed, but now they don't seem to want to help anyone. Maybe it's true that they are embarassed on the specs of their hardware, or also possibly they just don't think that it's worth losing their 'power' over the software used with their hardware by making things open (you'd be amazed how much this means to some vendors, sadly). It will happen one way or another eventually, so they're making assholes out of themselves just to buy themselves some time. No hardware stays unsupported for TOO long, but sadly it can be irrelevant long before it's supported and then there's not much point.
Would Xen be called a kernel? It just provides hardware-like virtual devices (on a virtual bus itself) which require specific drivers and support from the running OS, but in exchange for this you get very good performance and it's pretty simple to implement. The drawback of course is that it/requires/ support from the running system, but NetBSD (and others..) already supports it. Not hard really, all of the abstraction for new busses and hardware is there, and of course the glory of cross-compilation (which is only needed for the kernel).
I think that was his point. If people want a Debian derivative that's centered on newer platforms (with newer software? I haven't tried it), they'd use that, and still have at least some of the strenghts of Debian.
But I would have said that, apart from the specific features of Linux that some corporate users find useful, people who run Debian may as well run NetBSD. The stability is there WITHOUT being out of date, and the security is among the greatest. The portability is there too, and stronger than Debian's, since it includes cross-compiling of everything in addition to binary packages (simultaneously taking most of the advantage of Gentoo and Debian's package managers).
There are some drawbacks (no IA64 and PPC64... yet; and SMP is a bit behind Linux itself) but, for many users who are happy running stable software, it's right on the mark.
Personally I (currently) run Linux because it has the simplest [even if not always most reliable] support for all hardware I manage, which is growing as time goes by, and since I frequently give people convenient desktops (rather than maximally reliable systems) Linux is okay. But I do Gentoo, and regret it every time it takes a day or two to REALLY complete an installation; but am rewarded again when the software is relatively up-to-date and integrates well (by USE, basically).
I'll try Debian later, it could be just what I need. Or it could be a nightmare. Never know 'till you try.
Is UseDNS Off? It might be trying to find a reverse-DNS for its client and be running in to trouble. I think there's some other option related to this but I haven't had that problem in too long.
Does turning off X11 forwarding 'fix' the problem or does it still happen? I couldn't work that out just from your post.
Does the FTP server even do it? I always thought (but I haven't read the source so take it with a grain of salt) it just silently fetched an 'ls' and then used that. It can often take a second or two if you're on a slow server. And if it's the part of the command that would be local (yeah, it's intelligent - which is NOT possible in the shell's method) it just checks the local list. Neither of these need much code at all: it already has the code to get an ls from the server (and this is within the protocol standard) and the code to fetch a list of local files is a few lines at most, including error checking if your working directory disappears magically.
Slashdot Mirror
DFly will remain relevant for having a pretty relaxed but surprisingly stable development model. While there were still bugs that kept me from using it as a gateway (and software support problems that kept me from using it as a desktop), it never actually crashed or did anything harmful - it just couldn't route packets the way they should be routed - and nobody replied to my message on bugs@ or the IRC channel. I switched to NetBSD 3.0-beta and the same configs (for PF and inetd) worked. So I stuck with that. None of the same ACPI weirdness either.
FreeBSD 5 on the same machine could do almost nothing right at all, so I gave that up. I'm waiting for 5.4 release to make an assessment, because I didn't even get a chance to fetch sources this time.
Out of curiosty, has the new shutdown sync hack been resolved? From 5.3 and a while after, it wold take ages to sync disks, since buffers could be created anew even after shutdown - only three consecutive "nothing left" instances would finalise the syncing. This is unlike what every other OS does (since they don't generate new buffers after shutting everything down) so I'm guessing 5.3 introduced some bugs that needed this hack. So, is that over now or do we still have long-ass shutdowns?
The 'unofficial roadmap' you can find (http://www.feyrer.de/NetBSD/roadmap.html). For 3.0, some things are already in-tree for it (PF, PAM), but most of that hasn't even shown evidence of being attempted. I'm not sure which devs actually agree with that map, but it is clear to see they don't all believe they can do it. 3.0-beta currently offers very little 2.0 doesn't for a huge range of users, the most likely to be noticed being the wonderful PF (which is forwarding these packets now... and normalizing them!).
One note to PF newbies, if you want behavior like the other packet filters (linear top->bottom checking of rules, stopping at any matches), use 'quick' for every rule. It will save you headaches figuring out why some rules appear to be completely useless.
Back on topic, it appears NetBSD (or at least someone there) decided to use Solaris-like SMP locking (the same thing that 'killed' FreeBSD 5). We'll see how that pans out, or if it's even true: but suffice to say it's not there in the netbsd-3 branch yet.
I don't think you know what I mean at all. I didn't deny any of that. I am refuting that its (accused) move to replace Linux is not hampering its quality (where 'quality' is 'does what it's supposed to properly', not 'does what Linux does', which is a stupid argument).
Do you know why I dropped Linux on my gateway? It couldn't handle IPSec properly. On certain protocols (yes, it actually had protocol-specific bugs, even though IPSec is meant to be protocol agnostic) it would just drop packets without any clue as to what was happening. The exact same configurations on DragonFly and NetBSD worked exactly as expected. THAT is what I am talking about when I say quality. If a BSD says something will work in a stable branch, it will work. This is not the case in Linux. 2.6 is meant to be a stable branch, yet a lot of things either don't work or have huge debilitating bugs like this IPSec misfeature. I don't care if Linux' performance runs loops around NetBSD, if it doesn't do what it's supposed to and has no practical workarounds, THIS FAR INTO A STABLE BRANCH, it is not even worth considering.
And since NetBSD is gaining ground (albeit slowly) to be able to replace Linux installs for more and more applications, all the better. Others, too, will be able to replace Linux with a system that Works Properly All The Time, not just Works Properly in 2.6.8-rc3-mm2-bbq5.
FreeBSD 5.x is free but not very fast, and while this will improve over time, the bugginess and complexity in the meantime isn't worth it for most.
NetBSD got much faster in 2.0. It can now compete with FreeBSD 4 in UP, and can run a not-bad SMP (if you know what you're doing, that is).
OpenBSD is useful, because it doesn't stop you from running a text editor - in this case vi. That's a lot better than the 'default install' of a lot of Linux distributions I know.
The problem is that even the loopback interface can be sniffed on (usually only by root, admittedly, but still) so any authentication happening with sockets is going to be a bit on the dangerous side. Libraries are still in the protected address space of their host process, so there's no problem. I like daemons, don't get me wrong, but I wouldn't trust one to handle authentication - especially since there's no real advantage to it.
Now, if we were talking about network authentication with decent SSL or other encryption between daemon and client, that I could agree with. But I believe that's already been done in other ways...
Is that really what bothers you? I have to report that in spite of the PAM inclusion, NetBSD 3.0-beta is still a world of performance and efficiency, and EVERYTHING works properly. Things that always broke on Linux 2.6.11, for instance.
It's good that it's moving to be able to replace Linux, that means it can gain market share while still retaining its quality. What the hell is wrong with you? If implementing features of questionable design (even though the implementation, Open PAM, is about as good as you can get) kills an OS for you, you are going to have to ignore FreeBSD (why? because it has made nothing but bad design decisions lately, AND IT HAS THE SAME PAM IMPLEMENTATION) and Linux (one big bad design flaw, and it's the corporate monster you're afraid NetBSD will be).
NetBSD is probably the only system that is moving to corporate-worthy and Linux-replacing changes, while not actually losing any quality in the process. Yes the source tree is a bit bigger now. But yes it is also now more appealing to a large number of users who were previously stuck with Linux or FreeBSD so as to have a base-system PAM. If it increases market share without decreasing quality, it's a Good Thing. Linux does it almost every day, and Linux often does decrease quality.
Would Linux 2.6 be where it is if it had been conservatively developed on from 2.4? Short answer: No. Long answer: Definitely not.
Branching lets people use a continuing product with one development model while another version of the same product is worked on with another development model. After a certain agreed-upon stage of development, the roles change. For instance, the unstable branch gets to a stage of maturity, and it is made the stable branch.
That's why BSDs always have something stable and typically something getting new tech, and are going exactly where they should be. Meanwhile Linux has unbelievable numbers of bugs (Coverity alone found almost 1000 in 2.6.8, and 5 in NetBSD -current) and constant ABI incompatibilities - NPTL changes, IPSec changes, changes that mean old NVidia video drivers don't work any more, and so on. Why? No good reason. And it's all done in a 'stable' branch because Linus doesn't see a need to fork right now. So people are actually using an active development branch that is labelled a stable branch, and are surprised when something breaks or requires rebuilding significant userland components.
When Windows can use algorithms other than DES and 3DES for IPSec, then we'll talk. And where are the static keys? It wouldn't be so bad if its twisted way of setting up key exchanges was workable, but it's only barely so. And IPSec, if you'd ever used it properly, you would know to be a VERY valuable security and privacy feature, yet in Windows it's on barely workable levels. Linux got a not-too-bad IPSec in kernel 2.6, and while it's still a lot flakier than any BSD (like having to use -m tunnel), it actually works and can use algorithms that aren't yet obsolete. And it can use them properly. Static keys, IKE, tunnel, transport, whatever, it works. Windows is excruciating and crippled in this respect, and it's a huge lacking in its security capabilities.
That's why many *nix's don't need to make huge progress: they're already on the bleeding edge. With Windows so far behind in respects like these, it need all the improvement it can get.
Wrong. They would have to modify it, and hence release the sources (as per GPL). Since there are no sources and no admitting they did so, none of those products have Linux. On the other hand, it does have things from NetBSD in hardware and software (see http://www.feyrer.de/NetBSD/blog.html - search 'PS2' (gets you an XIII-related piece) and 'Playstation' (the latter being the PSP itself). I say this because linking to these from Slash seems to break.
I guess I should ask you, is blind zealous ignorance bliss?
You mixed up their lines.
h tm
http://www.geocities.com/Hollywood/7606/pulpscri.
Admittedly not the exact script used in the movie, but it wasn't changed much (less "I think"s and so on). Here's the appropriate section:
ZED: Bring out The Gimp. MAYNARD: I think The Gimp's asleep. ZED: Well, I guess you'll just wake 'em up then, won't you?
'make install clean' does the same thing but without re-forking and with any caches make could have had (which most cleans won't need, admittedly). Learning about make's behavior is highly recommended: don't be like the 90% of stupid guides and tutorials I've seen which insist on using && to do the same thing with more overhead and typing.
An extra bonus is that arguments persist for all arguments to a make, for instance:
make -j3 -DDEBUG depend all install clean (all targets get -j3 and -DDEBUG)
make -j3 -DDEBUG depend && make all (and so on - only first target gets those flags, and repeating them all is highly impractical).
This has been a public service announcement by someone with a clue.
You would still only have the same static perspective, so even skewing won't 'create' things you would see from a different perspective (hard to explain but you should already know what I mean). Even Active Camouflage uses a similarly flawed approach, in that it doesn't look behind it, but uses a static 'before' image that a 'monitor' mapped on an arbitrary surface (e.g. the trenchcoat) does its best to display. It's a neat party trick but it doesn't allow changing perspective or anything else useful like that. But, when we have a sensor surface and a monitor surface (with enough colours) AND a real time processor capable of compensating for the differences, and possible lighting issues on both sides, then we would have it.. then all it takes is to merge the sensing and monitoring into one surface. That's the ideal goal, I'm sure, since it's the only way to get anywhere near believable transparency. Maybe a decade off, but maybe less too - never underestimate research grants and caffeine.
I personally don't think that having graphics that don't differ enough from other games is going to water down the game itself. Wind Waker made a huge step in the right direction by taking a risk with Cel Shading, which was very successful according to just about everyone who's actually played it. It looks great and the graphics won't get out-dated quickly because the style has survived in cartoons for decades. The step to realism adds the risk of becoming dated (since something else can be 'more' realistic) but on the other hand it also appeals to a different audience. And, fancy that, life is life. If every game was perfectly realistic, of course they'd all look the same!
Besides that, the 3D Zeldas (at least OoT) did not look at all like their early development snapshots... like the early OoT that looked like Mario 64 with a sword. This game might take new directions (if there's still time) that will still make it unique, and if not, there'll always be the good gameplay and everything else that IS unique to the Zelda experience.
Innovation has always been a Zelda trademark: after the transition to 3D in OoT, MM completely changed how Zeldas were structured (essentially in putting much more focus into optional quests, and the time looping system) which lead to much more interesting game play, and then Wind Waker changed how Zelda WORLDS were structured, and completely took out the idea that your abilities in combat should be limited - as long as you know what you're doing you can pull off unbelievable BS in battles and get out unscathed. Gameplay innovation is always a Zelda thing and I would have to say it's accelerating, at least in the 3D ones (I can't speak for Oracle* and Minish Cap). So no amount of graphic lameness can kill what an awesome game this next one will be, if the trend is to be followed.
It's nice that your country supports free speech, isn't it? You could show your love for your freedoms by actually making good use of them, and posting things that actually make sense or, I know this sounds crazy, have some factual or logical basis. Spelling is nice too, but don't feel it's somehow more important than knowing what you're talking about.
Theo was asking for the documentation on behalf of the whole FOSS OS community, but he just happens to be among the only people with the balls to actually speak up and make a difference. OpenBSD may be the first to benefit from the documentation, or it may not, it doesn't really matter. If Adaptec wants to be taken seriously by the large number of FOSS OS users, it's going to have to actually at least provide documentation to developers and the community so that the software support for their hardware is good. I talked about this before: to a *nix user, support for the hardware they will buy comes FIRST, THEN come quality, availability and cost (in an order depending on the user). No sane admin would buy hardware he knows won't work or will work so shoddily under his OS Of Choice that it's not worth its extra 'value'.
Using binary junk, already impossible to 'use with some modifications', is not proper software support. Using drivers made through assumption rather than documentation is also risky business. Adaptec only have to release the documentation for their hardware to merit a lot more respect from the community, which translates into more purchases. Nobody can possibly argue this. Now, they may have their reasons for withholding the documentation, and it is their right; but it's up to them to decide if they want to risk losing sales (and they will) for their pride or whatever they're protecting. It is a public opinion that they are choosing wrong.
(This is from someone with some boobie experience)
You're the idiot, and it's in not realising that while calling GNU/Linux just 'Linux' is just fine, calling KDE/GNOME/etc 'Linux' is idiocy. It runs just as well on any BSD, and other platforms too I've heard. Yet the same icons are still there, and are drawn the same. Therefore the icons have NOTHING to do with Linux, except that you can get them drawn on a Linux box. The same way, you can take the images and stick them on a Windows box, within resolution limits. Now, they we're MADE for the Windows system of course, they were for their desktop environment or window manager, but they weren't made for Linux either - for all you know it could have been made under a BSD.
I keep getting asked about my WindowMaker environment, "so is that Linux?", and I have to explain that, no it's not, it's WindowMaker in an XOrg server, but yes the kernel is Linux, not that it matters here since its effects on my graphical interface are completely trivial. Of course this is usually asked by the people who think that there are only three systems out there (MacOS, Windows, and Linux - and that all of them only run on x86 because there is no other architecture, and what's an architecture?), and so on.
But you're not much better. Classing OS-agnostic software like KDE or GNOME as Linux just because it happens to be MOST OFTEN USED in Linux, and saying that separating kernel from software is self masturbation and completely pointless, is idiocy of the highest order. Hell, the ICONS, which are completely untied to the kernel, definitely shouldn't be stuck with the OS title.
Even if OpenBSD DID matter very little (hint: this is not the case), releasing the documentation means everyone gets better drivers (reiterate: better. Documentation is better than assumption) and good management tools. People want to buy hardware to run Linux, *BSD, whatever on, and if the support is good (even if it's just documentation!) the product is good.
Look at the Ti wireless chipset versus the offerings of Prism*. The Ti chipset is cheap to manufacture and very popular now, yes it sucks hard but it works well enough for most - but because its support is close to none (and if you say "but acx100 exists!", you obviously haven't tried it...), buying it is a very bad move. If documentation was released, solid drivers could be written and the hardware would suddenly become worth buying for a HUGE number of users - and this would be fair because the chipset is now in (no kidding) the majority of commercial wireless cards here in Australia and who knows where else.
God forbid a developer and a major contributor to our freedoms should be upset that a corporation has held off releasing documentation after months of 'negotiation'. He may chew people out on mailing lists, but that does not make an asshole. His way of dealing with people personally might just be a little intolerant, but he has done much more for the open source community than any other single leader - and he does NOT need to sit on a huge platform of sponsorship and hype to make a difference. What did Linus do? Write a kernel with a license that corporations decided was good in fighting the Microsoft monopoly. Bam, it's done. Theo actually swam upstream with little help and brought a good project with good ideals which DO help others - OpenSSH being everyone's favorite example. Where would you be without it? Up sh!t creek.
If you don't use OpenBSD because of its project leader, you may as well never use or communicate with any OpenSSH clients or servers and you can forget about PF. Just to be a real self righteous prick you may as well not use the internet at all just in case your packets pass through a server which an 'asshole' contributed to. Or a hardware design. In fact, how do you know assholes didn't grow the trees that maintain your oxygen supply? May as well stop breathing.
How it is a serious drawback? It's the point of the BSD license; maximal freedom while retaining copyright. It's why (see http://www.feyrer.de/NetBSD/blog.html ) NetBSD is used in countless embedded devices silently, in contrast with Linux which requires re-releasing changes made and announcing that they're using it.
You said that the problem with the BSD license is that it isn't a clone of the GPL, which implies you're a GPL nazi, and as a wonderful side note you completely missed the point of the article and thread.
Theo's complaining that there is no documentation with which to write properly open management tools and improve existing drivers, and so on. This has NOTHING to do with the BSD license. BSD projects can (and do) include GPL source in the base systems, but they prefer not to. It wouldn't matter what license they had in this case, because if you look closely, there's no documentation being released to Linux developers either - but they don't seem to mind because they only care if it works, not how well or securely or whatever.
So, yes, you have no idea what you're talking about and should probably read the article and the different licenses (just for clarity), before someone with less restraint than me responds to your posts.
Are you kidding? In the early days (pre-2.4 Linux) Adaptec wrote SCSI drivers for FreeBSD because it had the GOOD SCSI subsystem and then ported them to Linux when they had the time. FreeBSD's were still more solid just because of the system itself being solid, and being the first to get support helped too.
The situation hasn't really changed, but now they don't seem to want to help anyone. Maybe it's true that they are embarassed on the specs of their hardware, or also possibly they just don't think that it's worth losing their 'power' over the software used with their hardware by making things open (you'd be amazed how much this means to some vendors, sadly). It will happen one way or another eventually, so they're making assholes out of themselves just to buy themselves some time. No hardware stays unsupported for TOO long, but sadly it can be irrelevant long before it's supported and then there's not much point.
Would Xen be called a kernel? It just provides hardware-like virtual devices (on a virtual bus itself) which require specific drivers and support from the running OS, but in exchange for this you get very good performance and it's pretty simple to implement. The drawback of course is that it /requires/ support from the running system, but NetBSD (and others..) already supports it. Not hard really, all of the abstraction for new busses and hardware is there, and of course the glory of cross-compilation (which is only needed for the kernel).
I think that was his point. If people want a Debian derivative that's centered on newer platforms (with newer software? I haven't tried it), they'd use that, and still have at least some of the strenghts of Debian.
But I would have said that, apart from the specific features of Linux that some corporate users find useful, people who run Debian may as well run NetBSD. The stability is there WITHOUT being out of date, and the security is among the greatest. The portability is there too, and stronger than Debian's, since it includes cross-compiling of everything in addition to binary packages (simultaneously taking most of the advantage of Gentoo and Debian's package managers).
There are some drawbacks (no IA64 and PPC64... yet; and SMP is a bit behind Linux itself) but, for many users who are happy running stable software, it's right on the mark.
Personally I (currently) run Linux because it has the simplest [even if not always most reliable] support for all hardware I manage, which is growing as time goes by, and since I frequently give people convenient desktops (rather than maximally reliable systems) Linux is okay. But I do Gentoo, and regret it every time it takes a day or two to REALLY complete an installation; but am rewarded again when the software is relatively up-to-date and integrates well (by USE, basically).
I'll try Debian later, it could be just what I need. Or it could be a nightmare. Never know 'till you try.
Oh. Sensible. Yeah, I guess I should have read the manpage instead of speculating on observation, but admittedly it's more fun this way.
Keep up the good work!
And... what's your point? Relevant to what I said, that is.
Is UseDNS Off? It might be trying to find a reverse-DNS for its client and be running in to trouble. I think there's some other option related to this but I haven't had that problem in too long.
Does turning off X11 forwarding 'fix' the problem or does it still happen? I couldn't work that out just from your post.
Does the FTP server even do it? I always thought (but I haven't read the source so take it with a grain of salt) it just silently fetched an 'ls' and then used that. It can often take a second or two if you're on a slow server. And if it's the part of the command that would be local (yeah, it's intelligent - which is NOT possible in the shell's method) it just checks the local list. Neither of these need much code at all: it already has the code to get an ls from the server (and this is within the protocol standard) and the code to fetch a list of local files is a few lines at most, including error checking if your working directory disappears magically.