> I use it exclusively. VA has had no trouble with using it on Sourceforge. I have never lost any data.
Really really really freakin good for you. Most owners of firestone tires are still in one piece too. On the other hand, unless you just recently upgraded to the most bleeding edge version of ReiserFS, don't hit suspend on that laptop -- causes unrecoverable filesystem corruption. But hey, my fault right? I should have used the latest version even when that was the latest version, the fact that a bug may get caught in the future is no excuse to not use it now, right?
I may come back to ReiserFS in a couple years. I've been burned too badly with it now.
Last I checked, physics students get textbooks too. Last I checked, I wasn't enrolled in a semester-long course on how to use your goddamn application (the generic "you"). If it isn't worth the bother to document, it isn't worth mine to use. And there *are* alternatives I will pay for if necessary.
> 4) If you don't like it, don't use it. Better yet, if you don't like it, fix it! There's nothing stopping you from writing better documentation if you find it
You want documentation written by people who needed the documentation in the first place and didn't get any? Neat trick. I think I'll write a treatise on nuclear physics in order to teach myself.
So that he doesn't get taxed as a for-profit business. Non-profit doesn't mean you can't draw a reasonable (or even comparatively handsome) salary if you choose to take one.
> I'm NetBSD user. I won't tell you whether there is 140, 1400 or 14000 NetBSD users because I don't really know...
YHBT. HAND. This guy you responded to is a troll who posts the exact same post in every single BSD article. Just ignore him, he's just another reason I normally browse at threshold 2 til I get bored.
Just because Americans can't make beer that doesn't taste like mouldy water doesn't mean that Canadians are equally challenged.
Next time you're up in the great white north try and get your hands on something made by Big Rock breweries of Calgary. That's good beer.
Never heard of them. Just as you've likely never heard of Left Hand or Wynkoop or Broadway Brewing or any of the HUNDREDS of craft breweries in the US, probably an order of magnitude more than any other country in the world. Those three are just three ones in Colorado alone (home of Coors, lightly flavored spring water in a can) that I could name off the top of my head.
We all carry six-shooters and wear stetson hats too, you know?
If I understand correctly HURD and probably other Microkernels can run at lot more stuff in userland and that could at least be a advantage when you try to build a very secure system. If Theo is really posting on./ today, it would be nice of him to eloborate a little more about this general thoughts on kernel design.
In theory. In theory, microkernels could just swap out pieces of the system for independently developed implementations, and a change in one component need only affect that component (orthogonality). In practice, microkernels tend to just replace function calls with messages and their components remain tightly coupled as ever, so a failure (such as a security flaw) in one will tend to cascade to the other components in the system. Projects like OSKit offer hope for a more orthogonal OS design, but I'm not holding my breath.
> I'm glad that there are still geeks out there that aren't ashamed to admit to enjoying steriotypical geek food like Pizza and Beer
Pizza maybe, I've never seen beer associated with geekdom. Bunch of namby-pambies with their Jolt Cola usually, I prefer to code with a nice thick guiness in hand (tho not with beer, i like fat tire with my pizza)
> The initial reaction here seems to be that this is a bad idea. But what's wrong with bringing a object request broker architecture to an essentially monolithic kernel?
Nothing, but they didn't bring an architecture to the kernel, they just ported ORBit to it. Grafted it in with duct tape and baling twine, really. I don't even see anything valuable coming out of this as a side effect, such as a generic userland/kernel IPC interface like STREAMS or FreeBSD netgraph, just some libc compatibility macro hacks... *shudder*
Oh well, everyone's entitled to their own fun projects.
First of all, the existing Windows interface is alright, you can virtualy do anything you can with Gnome, and it does look and run sleeker.
Bah. How about multiple desktops? Yes, I know there's a zillion of those I can find off nonags, and they're all buggier than a Bangkok summer. The one on the resource kit is actually the worst one yet. A DOS box with less than completely crappy terminal handling would be nice too (try running w3m or just emacs over win2k's telnet). I wouldn't mind being able to move windows with alt-drag also.
90,000 POS terminals that can run on generic hardware, with hardware+licensing savings on the order of about $3,000 per cash register ~= $100M/yr in savings over a 3-year equipment life...
Three THOUSAND? Where the HELL did you pull that figure from? You don't exactly put Win2K Server on a POS box, much less buy a separate CD copy for each one.
His first action? "Well, let's get on the phone with the Apache people!" When I quietly informed him that there wasn't a specific "Apache people" to get on the phone with, he was utterly confused
A quick trip to www.apache.org would have put the lie to your answer. Apache is tightly managed by a group of developers, all of whom have names. You can even peruse the cvs logs to find the name of the developers who worked on that particular piece of code. You won't get telephone support, but you *can* send in apache bug reports, which are responded to. If that's not good enough, you can also purchase support contracts for apache from a number of companies. Tell me you did something other than throw up your hands?
Btw.. I'm calling for a unified packaging system for the unixes and it requires and first of all it requires a unified FHS. What efforts are being put into that out there?
I'm trying not to sound crass here, but if you were putting serious effort into your system, you'd know the answer better than anyone here. As an aside, I have many reasons to believe it's misguided to have your unified packaging system require a unified filesystem. First, you're the tail wagging the dog. Show that your system adds value. Redhat users have rpm, debian has apt, bsd has ports. You have to beat those or they have no reason to switch. Second, good luck getting solaris and slackware to see eye to eye.... or by "unixes" do you just mean linux? Lastly, I suspect your rigid filesystem standard would simply fall down in the face of complexities like a multi-architecture network. There is no One Right Way To Do It, especially when there's more than one "It".
Compaq, IBM, and Dell all sell systems with Linux on them, and they stand behind their systems in terms of compatibility. You install a new device that is buggy on Linux, their support guys will help you, or they'll tell you it isn't officially supported hardware, and see if there are workarounds -- same as a MS tech will tell you about devices not on the HCL.
But if you get a POS system (touchscreen, cardreader, cash drawer) based on OS/2 or DOS or Java (don't know what they run under the Java) then just go ahead and slap linux on it and things break, what the heck is the vendor *supposed* to do? They don't know any more than you do about running Linux on the hardware, most likely *less*, since you're the one being the guinea pig.
On the other hand, if you purchase a POS system from a vendor that supports Linux and it doesn't work as advertised, then you need look no further than the vendor that sold you the system.
And for the mutants in the crowd with three hands, on that hand if you homebrewed this POS system, you can't hold anyone to support it but yourself. If you build your own car and it breaks down because you assembled it with parts that were never made to be fitted to each other, you don't have a car maker to hold responsible either.
I had a caller once say "I think I broke the internet". I said "oh, well you're going to have to pay for that". I *hated* callers that jumped right into detail and their pet theory before even describing what the problem *was*. "sunray8 is down, you need to reboot it.". "uh no, i'm on sunray8 right now, tell me what you see on your screen, please?".
> Have you never heard of a UNION ? This is what they are for...
Tech workers, with the exception of telcos, are not unionized. In some areas (defense industry tech workers for example) they are *prohibited* by law from unionizing. Look, it doesn't matter what you think of unions, they just aren't available in this circumstance.
Wow. You're me three years ago, full of all kinds of rage. I'm not going to throw any platitudes about motivation your way, there's almost nothing more draining than working at the helplessdesk. Here's some unsolicited advice instead:
1. Start looking for other helpdesk work. You're qualified, obviously. Don't tell them you're burning out, of course, just use common sense, you'll think of something to say about why you're leaving (and the recruiter knows why most helpdesk people make lateral job moves anyway). You might end up in a place exactly as bad, but you'll have at least months of breathing room enjoying your escape from the old company, and probably a small raise to go with it. Take that exit interview if they offer it, and unload about what you think went wrong -- about the company, do NOT go after individual people.
2. Read man pages on your OS like crazy. Tinker. Have a friend break stuff and see how quickly you can find and fix it. Put unix system administration on your resume, and recruiters will eat that up. Learn NT -- warez a copy for home if you can (not off the net, just find someone who has a CD). Lose the OS religion, think of it as knowing your enemy if you don't ever want to do NT admin (I sure don't). Don't imagine that sysadmins have any easier a life than phone drones tho, but maybe you'll find it your calling still.
3. Pick up a computing book, one of those high level architecture type books, like Modern Operating Systems (Tanenbaum) or TCP/IP illustrated. Using some high level language you like, like perl, python, MOO, or even shell, go implement some of the ideas. Doesn't have to be fast or complete. Stick a web interface onto it. Put it on your personal website (go get one from xoom/geocities/wherever), explaining how it works. Now you're an educational resource. Put this personal project on your resume. Now do another. (N.B. I haven't actually made my little projects educational like that. Wish I did do that for my compiler projects in python)
Um, no. That's an announcement site for the standard ports collection. I am talking about port content that updates via CVS or cvsup (which I understand is the case for the OpenSSL port, before it was marked FORBIDDEN). Dont answer questions I didn't even ask.
> The HTML rendering engine needs work in some places, but people should keep in mind that this is the KDE file browser.
Not so, Konquerer is the KDE generic browser. As in it is able to select and view arbitrary content via a variety of access methods. The file listing component need have nothing to do with the HTML renderer -- and probably shouldnt, since I much prefer a column/graph component for managing large numbers of files.
I'm not terribly enthused about having to do a whole damn make world just to get a version of OpenSSH it'll be happy with tho...
Good thing I didn't waste time with the kde2 freebsd port. Now I get to download the whole ball of wax for 2.01. Over a 56K modem. 56K if I'm lucky. I just do not get it, I update the OS with cvsup, I update the ports collection with cvsup... why can't I get one single PORT that updates with cvsup instead of downloading the WHOLE damn set all over again? This is the same beef I have with rpm's.
--
Re:The problem is in the dependency database
on
An RPM Port Of APT
·
· Score: 3
> What we need is a packaging system that can correctly detect whether or not dependent packages are installed without having to have a database
You've just described FreeBSD's ports collection. Every port I've installed checks for files (using the standard binary and library paths) and not packages. Ports is not perfect: it builds BSD packages, which are so primitive and hard to manage, I don't even bother uninstalling them, i just write new versions over them (so it effectively has no version control). It'd be nice to have it build RPMs instead, even if rpm isn't the best tool out there.
Best of all worlds would be something with the rich command syntax of rpm, the package flexibility of solaris packages (where you can edit the packing list of an installed package) and the script-like flexibility of ports (which is all makefile-based, so you can edit the logic of individual ports, or all ports)
Slashdot Mirror
> I use it exclusively. VA has had no trouble with using it on Sourceforge. I have never lost any data.
Really really really freakin good for you. Most owners of firestone tires are still in one piece too. On the other hand, unless you just recently upgraded to the most bleeding edge version of ReiserFS, don't hit suspend on that laptop -- causes unrecoverable filesystem corruption. But hey, my fault right? I should have used the latest version even when that was the latest version, the fact that a bug may get caught in the future is no excuse to not use it now, right?
I may come back to ReiserFS in a couple years. I've been burned too badly with it now.
--
> Actually, some of us do have in-depth knowledge of signal processing. I've been playing with my own CODEC projects in my (near-mythical) free time.
You'll just be next to be sued. Who says we don't have thought police?
--
Last I checked, physics students get textbooks too. Last I checked, I wasn't enrolled in a semester-long course on how to use your goddamn application (the generic "you"). If it isn't worth the bother to document, it isn't worth mine to use. And there *are* alternatives I will pay for if necessary.
--
> 4) If you don't like it, don't use it. Better yet, if you don't like it, fix it! There's nothing stopping you from writing better documentation if you find it
... um ... move his legs real fast.
You want documentation written by people who needed the documentation in the first place and didn't get any? Neat trick. I think I'll write a treatise on nuclear physics in order to teach myself.
See Dick
--
> Why must it be a non-profit?
So that he doesn't get taxed as a for-profit business. Non-profit doesn't mean you can't draw a reasonable (or even comparatively handsome) salary if you choose to take one.
--
> Could you back up this statement?
Bill Joy was one of the original authors of BSD. And vi too (*sigh*).
--
> I'm NetBSD user. I won't tell you whether there is 140, 1400 or 14000 NetBSD users because I don't really know ...
YHBT. HAND. This guy you responded to is a troll who posts the exact same post in every single BSD article. Just ignore him, he's just another reason I normally browse at threshold 2 til I get bored.
--
Just because Americans can't make beer that doesn't taste like mouldy water doesn't mean that Canadians are equally challenged.
Next time you're up in the great white north try and get your hands on something made by Big Rock breweries of Calgary. That's good beer.
Never heard of them. Just as you've likely never heard of Left Hand or Wynkoop or Broadway Brewing or any of the HUNDREDS of craft breweries in the US, probably an order of magnitude more than any other country in the world. Those three are just three ones in Colorado alone (home of Coors, lightly flavored spring water in a can) that I could name off the top of my head.
We all carry six-shooters and wear stetson hats too, you know?
--
> I said utopia
An all-too appropriate word, considering the word means "nowhere". Show me paradise in any OS today. Lead me to the Buddha in the machine.
--
If I understand correctly HURD and probably other Microkernels can run at lot more stuff in userland and that could at least be a advantage when you try to build a very secure system. If Theo is really posting on ./ today, it would be nice of him to eloborate a little more about this general thoughts on kernel design.
In theory. In theory, microkernels could just swap out pieces of the system for independently developed implementations, and a change in one component need only affect that component (orthogonality). In practice, microkernels tend to just replace function calls with messages and their components remain tightly coupled as ever, so a failure (such as a security flaw) in one will tend to cascade to the other components in the system. Projects like OSKit offer hope for a more orthogonal OS design, but I'm not holding my breath.
--
> I'm glad that there are still geeks out there that aren't ashamed to admit to enjoying steriotypical geek food like Pizza and Beer
Pizza maybe, I've never seen beer associated with geekdom. Bunch of namby-pambies with their Jolt Cola usually, I prefer to code with a nice thick guiness in hand (tho not with beer, i like fat tire with my pizza)
For the record, I also hate twinkies.
--
> The initial reaction here seems to be that this is a bad idea. But what's wrong with bringing a object request broker architecture to an essentially monolithic kernel?
... *shudder*
Nothing, but they didn't bring an architecture to the kernel, they just ported ORBit to it. Grafted it in with duct tape and baling twine, really. I don't even see anything valuable coming out of this as a side effect, such as a generic userland/kernel IPC interface like STREAMS or FreeBSD netgraph, just some libc compatibility macro hacks
Oh well, everyone's entitled to their own fun projects.
--
> Which alloys, compounds, solders, construction methods, etc. hold up best in space.
:)
Sure, all they need to do is go out there and grab it so they can look at the physical damage. You volunteering?
--
First of all, the existing Windows interface is alright, you can virtualy do anything you can with Gnome, and it does look and run sleeker.
Bah. How about multiple desktops? Yes, I know there's a zillion of those I can find off nonags, and they're all buggier than a Bangkok summer. The one on the resource kit is actually the worst one yet. A DOS box with less than completely crappy terminal handling would be nice too (try running w3m or just emacs over win2k's telnet). I wouldn't mind being able to move windows with alt-drag also.
--
90,000 POS terminals that can run on generic hardware, with hardware+licensing savings on the order of about $3,000 per cash register ~= $100M/yr in savings over a 3-year equipment life...
Three THOUSAND? Where the HELL did you pull that figure from? You don't exactly put Win2K Server on a POS box, much less buy a separate CD copy for each one.
--
His first action? "Well, let's get on the phone with the Apache people!" When I quietly informed him that there wasn't a specific "Apache people" to get on the phone with, he was utterly confused
A quick trip to www.apache.org would have put the lie to your answer. Apache is tightly managed by a group of developers, all of whom have names. You can even peruse the cvs logs to find the name of the developers who worked on that particular piece of code. You won't get telephone support, but you *can* send in apache bug reports, which are responded to. If that's not good enough, you can also purchase support contracts for apache from a number of companies. Tell me you did something other than throw up your hands?
--
Btw.. I'm calling for a unified packaging system for the unixes and it requires and first of all it requires a unified FHS. What efforts are being put into that out there?
I'm trying not to sound crass here, but if you were putting serious effort into your system, you'd know the answer better than anyone here. As an aside, I have many reasons to believe it's misguided to have your unified packaging system require a unified filesystem. First, you're the tail wagging the dog. Show that your system adds value. Redhat users have rpm, debian has apt, bsd has ports. You have to beat those or they have no reason to switch. Second, good luck getting solaris and slackware to see eye to eye.... or by "unixes" do you just mean linux? Lastly, I suspect your rigid filesystem standard would simply fall down in the face of complexities like a multi-architecture network. There is no One Right Way To Do It, especially when there's more than one "It".
--
Compaq, IBM, and Dell all sell systems with Linux on them, and they stand behind their systems in terms of compatibility. You install a new device that is buggy on Linux, their support guys will help you, or they'll tell you it isn't officially supported hardware, and see if there are workarounds -- same as a MS tech will tell you about devices not on the HCL.
But if you get a POS system (touchscreen, cardreader, cash drawer) based on OS/2 or DOS or Java (don't know what they run under the Java) then just go ahead and slap linux on it and things break, what the heck is the vendor *supposed* to do? They don't know any more than you do about running Linux on the hardware, most likely *less*, since you're the one being the guinea pig.
On the other hand, if you purchase a POS system from a vendor that supports Linux and it doesn't work as advertised, then you need look no further than the vendor that sold you the system.
And for the mutants in the crowd with three hands, on that hand if you homebrewed this POS system, you can't hold anyone to support it but yourself. If you build your own car and it breaks down because you assembled it with parts that were never made to be fitted to each other, you don't have a car maker to hold responsible either.
--
I had a caller once say "I think I broke the internet". I said "oh, well you're going to have to pay for that". I *hated* callers that jumped right into detail and their pet theory before even describing what the problem *was*. "sunray8 is down, you need to reboot it.". "uh no, i'm on sunray8 right now, tell me what you see on your screen, please?".
--
> Have you never heard of a UNION ? This is what they are for...
Tech workers, with the exception of telcos, are not unionized. In some areas (defense industry tech workers for example) they are *prohibited* by law from unionizing. Look, it doesn't matter what you think of unions, they just aren't available in this circumstance.
--
Wow. You're me three years ago, full of all kinds of rage. I'm not going to throw any platitudes about motivation your way, there's almost nothing more draining than working at the helplessdesk. Here's some unsolicited advice instead:
1. Start looking for other helpdesk work. You're qualified, obviously. Don't tell them you're burning out, of course, just use common sense, you'll think of something to say about why you're leaving (and the recruiter knows why most helpdesk people make lateral job moves anyway). You might end up in a place exactly as bad, but you'll have at least months of breathing room enjoying your escape from the old company, and probably a small raise to go with it. Take that exit interview if they offer it, and unload about what you think went wrong -- about the company, do NOT go after individual people.
2. Read man pages on your OS like crazy. Tinker. Have a friend break stuff and see how quickly you can find and fix it. Put unix system administration on your resume, and recruiters will eat that up. Learn NT -- warez a copy for home if you can (not off the net, just find someone who has a CD). Lose the OS religion, think of it as knowing your enemy if you don't ever want to do NT admin (I sure don't). Don't imagine that sysadmins have any easier a life than phone drones tho, but maybe you'll find it your calling still.
3. Pick up a computing book, one of those high level architecture type books, like Modern Operating Systems (Tanenbaum) or TCP/IP illustrated. Using some high level language you like, like perl, python, MOO, or even shell, go implement some of the ideas. Doesn't have to be fast or complete. Stick a web interface onto it. Put it on your personal website (go get one from xoom/geocities/wherever), explaining how it works. Now you're an educational resource. Put this personal project on your resume. Now do another. (N.B. I haven't actually made my little projects educational like that. Wish I did do that for my compiler projects in python)
Hope some of these help.
--
> www.freshports.org end of story
Um, no. That's an announcement site for the standard ports collection. I am talking about port content that updates via CVS or cvsup (which I understand is the case for the OpenSSL port, before it was marked FORBIDDEN). Dont answer questions I didn't even ask.
--
> The HTML rendering engine needs work in some places, but people should keep in mind that this is the KDE file browser.
Not so, Konquerer is the KDE generic browser. As in it is able to select and view arbitrary content via a variety of access methods. The file listing component need have nothing to do with the HTML renderer -- and probably shouldnt, since I much prefer a column/graph component for managing large numbers of files.
I'm not terribly enthused about having to do a whole damn make world just to get a version of OpenSSH it'll be happy with tho...
--
Good thing I didn't waste time with the kde2 freebsd port. Now I get to download the whole ball of wax for 2.01. Over a 56K modem. 56K if I'm lucky. I just do not get it, I update the OS with cvsup, I update the ports collection with cvsup ... why can't I get one single PORT that updates with cvsup instead of downloading the WHOLE damn set all over again? This is the same beef I have with rpm's.
--
> What we need is a packaging system that can correctly detect whether or not dependent packages are installed without having to have a database
You've just described FreeBSD's ports collection. Every port I've installed checks for files (using the standard binary and library paths) and not packages. Ports is not perfect: it builds BSD packages, which are so primitive and hard to manage, I don't even bother uninstalling them, i just write new versions over them (so it effectively has no version control). It'd be nice to have it build RPMs instead, even if rpm isn't the best tool out there.
Best of all worlds would be something with the rich command syntax of rpm, the package flexibility of solaris packages (where you can edit the packing list of an installed package) and the script-like flexibility of ports (which is all makefile-based, so you can edit the logic of individual ports, or all ports)