I think we should tell Real Networks to go take a flying leap.
Real Networks is basically a company who has developed an entire market by keeping a single algorithm a secret. They basically implemented the "Real Time Streaming Protocol" and have kept it closed source and undocumented.
So that's their right you say? But they have an RFC on the topic! Why does a company have an RFC on a protocol, but yet has that RFC full of holes so you can't really build an implementation?
It's called pulling a Netscape with SSL, or pulling a Microsoft in general. In short, pollution of the landscape with misleading incorrect standards documentation.
Meanwhile, Real managed to "lock up" the streaming market for a while. They muscled a number of other streaming companies out of the market (not sure if any of them had better business practices) and continued to dress up their relatively tiny technological advance with GUIs and partner programs and so forth.
If Microsoft kills them and owns the market, we have really only Real and companies like them to blame, who have willfully created a market with misleading documentation and lawyers as barriers to entry, instead of keeping ahead technologically.
The great wall of China was built to keep out the northern invaders. However, it was a monumental failure. You simply can't wall off your entire country, and the invaders rode around the wall and attacked the country all the same.
This whole firewall scheme is much the same. It's a monumental effort doomed to failure. No matter how complete a wall is built, the information can simply find some way to go around it.
This is incorrect. You do not need to be running windows in order to use the Free version of BeOS.
You can install and launch the free version of BeOS from inside windows, OR you can install and launch the free version of BeOS without using any other OS. Ie. you can install it in its own partition and boot it directly from LILO or whatever.
I agree with everything Bezos said on the linked page.
This does nothing to adress the trivial patents they have filed on "1-Click" and "Affiliate Partners". These are not technological inventions, they are trivial tweaks of business practices. I will maintain my boycott unless enforcement of these patents ceases.
Of course you get twice the throughput. It's a software raid. Didn't I just say that?
The downside of course is that it wastes CPU and that it is completely useless if you're a linux user. More significantly, there is no way for the user to know these things by looking at the box. That's a real shame.
Hey folks, the FastTrack66 is not a raid at all. It is a software raid card, but implemented in the ON BOARD BIOS.
For the uninitiated, just because software is stored on a chip (in this case the card bios) rather than a disk, does not make it "hardware". This is commonly referred to as "firmware" but in reality is software that runs on the host CPU just like any piece of software.
The only difference is of course the BIOS calls you use to access the disk are able to understand the striping used on your disk. There are basically two advantages to this.
On crappy operating systems like DOS, where the BIOS is used to access the disk, you get a free software raid without having to load wacky TSRs. (Remember DOS has no such thing as a reasonable driver).
_IF_ you can get this properly supported under linux, you can have one set of disks going in software raid across multiple operating systems.
Thus, as I said previously, it's not a raid card at all. It's got pretty much no functionality for doing for doing raid at all. Given the fact that it's advertised as a hardware raid, I'd just as soon not purchase any products from Promise at all, until they learn to quit with the false advertising.
It always makes me somehow sad when people make one change to a distro (usually Red Hat or Debian) and name it something totally different as if it's largely their work.
Silly me, if I created UDMA 66 patches for Red Hat, I might get really arrogant and call them: "Josh's UDMA66 patches for Red Hat".
It's going to be OS X that puts a *NIX on the desk of my boss...not SUSE that he ditched.
Let me get this straight. You decided to install a _very_ early, pre-release of a beta operating system on your BOSS's desk? I guess you don't like your job.
As I said above, I for one find all attempts to register ANY trademark in an entirely farcical manner to be highly repugnant.
Having personal (and corporate) interest in this Linux thing, it goes double for all those who attempt to trademark "Linux".. (especially now.. after it's pretty obviously a power grab).
That said, I don't personally know my company (SuSE's) relationship with this firm, nor the exact details. I will be sure to mention it to Those Who Make Things Happen if it hasn't been done already.
We folks at SuSE are as respectful of the Linux trademark as the next guy. I'm sure some of our business folks will be chatting with them soon enough to find an agreeable solution to the problem. I'm sure that any solution agreeable to SuSE will include cessation of such silly antics.
At least all other UDMA/66 controllers are working.. the Promise one has proved a little more squirrely than most. I believe it is happy now, but I'm not making a promise.
If it doesn't work OOTB (Out Of The Box), we'll have a floppy image soon enough.
In fact, we've had UDMA floppy images for 66 for a bit now. If you'd like to try one send me a mail.
We tend to build the FTP and ISO images after we do the commercial release. It's not really any sort of grand scheme.. it's just we do the version which earns money first;-)
Thus, there are about 5 distributions to make:
German/European
US version for silly cryptolaws
German FTP version
"international" FTP version for silly cryptolaws
Eval version - condensed single-CD version
Making all of these and testing all of these doesn't happen overnight. It will be there shortly.
We tend to build the FTP and ISO images after we do the commercial release. It's not really any sort of grand scheme.. it's just we do the version which earns money first;-)
Thus, there are about 5 distributions to make:
German/European US version for silly cryptolaws German FTP version "international" FTP version for silly cryptolaws Eval version - condensed single-CD version
Making all of these and testing all of these doesn't happen overnight. It will be there shortly.
With the new _friendly_ gui install (at least we hope so), X is configured as part of the install.
This isn't so bad, as we use the VESA DDC to discover screen rates, and autodetect videocards, so usually there's nothing to 'configure'. If it manages to break, or if you don't like it, or if you don't even want to think about it, boot from CD#2 and use the familiar Yast1 install, sans-gui. The in-packaging hints suggest this is a possibility if you have trouble.
Well, I agree.. these would be pretty impressive... They have some issues though..
Star Office - not available for Alpha as binaries, questionable kosherness of redistributing on commercial product from SCSL-built sources, etc.
Netscape - Digital Unix netscape works, but isn't legal, as it requires runtime libraries from Compaq. Compaq I hear is working to allow this, but it will be some time. Netscape/alpha is yet to arrive.
Journalling Reiserfs and the tools for reiserfs were to go into SuSE 6.3. Some build issues kept it from being included into the standard kernel (unfortunately), but I expect to see patches to enable these features appear on ftp/web sites soon.
It might actually be in the US version, but I haven't had a chance to look yet.
I'm _very_ tempted to download the samba book to our corporate internal webserver. I probably will do this come monday.
I'm less than tickled, however, about the effect this will have on O'Reilly's sales. Do you think our employees will read through it and decide to buy a copy? Or do you think they'll decide not to buy a copy because they don't have to?
I think it _could_ help sales when the book is of sufficiently high quality and density that it is useful after reading it, useful on site, useful when troubleshooting. If it's so much fluff like some companies put out, though, then I can't imagine it would flourish in such an environment.
Somehow I suspect this isn't really us. Simple *bomb bomb bomb* *the president will fall* type stuff is unlikely to really even pass algorithmic muster.
I'm willing to keep pulling for it though... I drop a few phrases here and there in random emails. Maybe I should develop more friends in the Middle East...
f you are saying that OSS could not improve talk+finger because it was a broken concept, implying that OSS can only improve through evolution, then I disagree and again point at the WWW for a counter example. My guess at why the open software community did not improve instant messaging is that no one saw the need.
My points weren't meant to be consistent at all.. I should have unordered them.
I meant in point 5 that open source stuff is having a hard time cloning ICQ because it's broken. No one group has come up with the magic fix.. everyone is fixing it in a different way, etc.
I actually _did_ see the need for improving upon finger and talk, but only because I saw a roughly equivalent app at Farallon they developed but never shipped. It was called "Finger" and it was for the mac. I wanted to make a program for mac, win, unix that was backwards compatable with finger and talk (and write).. but this was in the days before I really knew how to program.
I think this is an example of something different. I was using finger and talk ten years ago for instant messaging. It worked excellent (finger was much more useful then than today and talk was simple and convenient on a text terminal) and surely it was open source? But commercial messaging systems has taken over because commercial companies rule the desktop market and probably also because of marketing. How much marketing does an initiative such as Gale get?
There are a few little nits I'd like to pick here.
talk and finger are okay, but have security problems (I assume you were alluding to these) and do not eqaul a program such as 'icq' which is a sort of talk, and finger, and nwrite, and a few other assorted concepts bundled into a neat little package. It's really a nice improvement in concept.
finger of course depends on the system being multi-user in concept, and it depends upon the other party haveing direct access to your machine.
ICQ and friends generally offer lots of wizzy things like multiple ways the view the conversation, the ability to send files directly, silly flower bitmaps, etc. Not all of these things are fundamentlly good, or good to have bundled into the client and/or protocol, but they attract users.
ICQ got started on Word Of Mouth. I watched people on IRC telling each other about it in 1996 or so. I even signed up, and have a _really_ early number. I dropped it because it was incredibly unstable. Even for windows.
I think it's generally hard for the OSS crowd to all clone a type of software at once that has a broken methodology. This is because all of them will try to fix it, and then you have a thousand cooks..:). Maybe the IETF "Instant Messaging" protocol I've heard rumours about will do much to relieve this.
No I'm talking about non RPM'ed code - stuff that isn't nicely packaged... you know... the stuff that's actually useful?
I think you're suggesting that only source-form programs are useful. SuSE does include all packages on the CD in source form except commercial ones, etc. These source form packages are stored in RPMs.
If you simply mean that you have some useful software which is not included in the distribution, and that this software does not build on SuSE, then I am quite surprised. I have built many many packages on SuSE (megaHal, new versions of vim, new versions of mutt, grip, gcd, in-house Wind River software, irc servers and clients.. etc etc) over a long period of time, all without trouble. There was a point (a long time ago) where libcurses wasn't in an ideal spot, but that's about as far as it goes for any trouble I've encountered.
If you truly are encountering lots of packages which refuse to build on SuSE, take a look at what's breaking. I suspect the package maintainer is making some silly assumptions. Example: some tcl software I acquired which had the following line at the start of the software #!/usr/local/bin/tclsh Obviously, this wasn't working as my tclsh was located in/usr/bin..
In any event, please do send criticisms to feedback@suse.de.
SuSE RPM's are great, they work really well, if you don't mind being totally limited to what they offer in RPM format. Same as above..
Please don't moderate this, it adds, nothing to the discusion, I'm merely replying to someone else.
Well, we're _certainly_ off the topic of IPOs. However, we're spot on the discussion you started about SuSE.
I remain curious, however: what are you feeding -nodeps into? I just issued the following command on my Suse 6.2 box: jrodman@Castrovalva:/usr/man >find . -name "*\.[123456789]\.*" -exec zgrep -l -e "-nodeps" {} \; I do have the allman package installed, so this will find the string -nodeps as part of any man page of any package in SuSE. I also spot-checked about 20 configure scripts, not finding this switch present in these either. The following are my findings:./man8/rpm.8.gz./allman/man8/rpm.8.gz
PS. How I wish i knew how to see the processor time used by a process and all its children. This grepping in compressed files would be a lovely thing to compare to NT.
ppp is supported. I've called ISPs with the customer on the line to explain to them what is misconfigured in their routers. Of course, it's usually much more simple than that....
As for kppp the reason you had a problem is this: Some dialer software locks the modem device. Some dialer software expects the ppp daemon to lock the modem device. The former is more "proper"... but the dialer developers probably have their own reasons (cross-platform issues perhaps?).
One solution would be for the dialer to always have the responsibility, and either have to run pppd with the 'lock' option, or lock the device itself. This requires custom patches to many dialers. These patches must be maintained, and are in some cases, messy.
Another solution would be to have more than one ppp configuration file. I'm not even going to discuss how messy this is.
The decision was to leave well enough alone, and let the configuration file/etc/ppp/options be set up to work with the majority of dialer software, and for kppp users to comment out the 'lock' line if they wished to use kppp. You see, kppp isn't even our recommended solution. The manual pretty clearly states wvdial is the recommended way to do it, and includes step-by-step instructions. In 6.2, it's even easier, as there's a straightforward configuration screen in YaST called Configure a PPP Network.
Why do we push people away from kppp? For 2 main reasons.
Wvdial generates better init strings.
Wvdial more reliably logs in, with tricky logic that can handle most script-based connections as well as PAP and CHAP.
Depending upon my memory, the other problem you could have been running into was kppp simply failing to work at all periodically. This was a kppp bug, and an update to it was available on the FTP site.
Slashdot Mirror
Real Networks is basically a company who has developed an entire market by keeping a single algorithm a secret. They basically implemented the "Real Time Streaming Protocol" and have kept it closed source and undocumented.
So that's their right you say? But they have an RFC on the topic! Why does a company have an RFC on a protocol, but yet has that RFC full of holes so you can't really build an implementation?
It's called pulling a Netscape with SSL, or pulling a Microsoft in general. In short, pollution of the landscape with misleading incorrect standards documentation.
Meanwhile, Real managed to "lock up" the streaming market for a while. They muscled a number of other streaming companies out of the market (not sure if any of them had better business practices) and continued to dress up their relatively tiny technological advance with GUIs and partner programs and so forth.
If Microsoft kills them and owns the market, we have really only Real and companies like them to blame, who have willfully created a market with misleading documentation and lawyers as barriers to entry, instead of keeping ahead technologically.
The great wall of China was built to keep out the northern invaders. However, it was a monumental failure. You simply can't wall off your entire country, and the invaders rode around the wall and attacked the country all the same.
This whole firewall scheme is much the same. It's a monumental effort doomed to failure. No matter how complete a wall is built, the information can simply find some way to go around it.
You can install and launch the free version of BeOS from inside windows, OR you can install and launch the free version of BeOS without using any other OS. Ie. you can install it in its own partition and boot it directly from LILO or whatever.
Read before you speak.
This does nothing to adress the trivial patents they have filed on "1-Click" and "Affiliate Partners". These are not technological inventions, they are trivial tweaks of business practices. I will maintain my boycott unless enforcement of these patents ceases.
Sorry about the bold.
Of course you get twice the throughput. It's a software raid. Didn't I just say that?
The downside of course is that it wastes CPU and that it is completely useless if you're a linux user. More significantly, there is no way for the user to know these things by looking at the box. That's a real shame.
Hey folks, the FastTrack66 is not a raid at all. It is a software raid card, but implemented in the ON BOARD BIOS.
For the uninitiated, just because software is stored on a chip (in this case the card bios) rather than a disk, does not make it "hardware". This is commonly referred to as "firmware" but in reality is software that runs on the host CPU just like any piece of software.
The only difference is of course the BIOS calls you use to access the disk are able to understand the striping used on your disk. There are basically two advantages to this.
Thus, as I said previously, it's not a raid card at all. It's got pretty much no functionality for doing for doing raid at all. Given the fact that it's advertised as a hardware raid, I'd just as soon not purchase any products from Promise at all, until they learn to quit with the false advertising.
Ho Hum. SuSE has this support already.
It always makes me somehow sad when people make one change to a distro (usually Red Hat or Debian) and name it something totally different as if it's largely their work.
Silly me, if I created UDMA 66 patches for Red Hat, I might get really arrogant and call them: "Josh's UDMA66 patches for Red Hat".
Shows what I know!
It's going to be OS X that puts a *NIX on the desk of my boss...not SUSE that he ditched.
Let me get this straight. You decided to install a _very_ early, pre-release of a beta operating system on your BOSS's desk? I guess you don't like your job.
Having personal (and corporate) interest in this Linux thing, it goes double for all those who attempt to trademark "Linux".. (especially now.. after it's pretty obviously a power grab).
That said, I don't personally know my company (SuSE's) relationship with this firm, nor the exact details. I will be sure to mention it to Those Who Make Things Happen if it hasn't been done already.
Oh, don't get your panties in a bunch.
We folks at SuSE are as respectful of the Linux trademark as the next guy. I'm sure some of our business folks will be chatting with them soon enough to find an agreeable solution to the problem. I'm sure that any solution agreeable to SuSE will include cessation of such silly antics.
Have a good day.
Then maybe you should have attended the bay area linux user's group a few months ago where he spoke about such things.
At least all other UDMA/66 controllers are working.. the Promise one has proved a little more squirrely than most. I believe it is happy now, but I'm not making a promise.
If it doesn't work OOTB (Out Of The Box), we'll have a floppy image soon enough.
In fact, we've had UDMA floppy images for 66 for a bit now. If you'd like to try one send me a mail.
We tend to build the FTP and ISO images after we do the commercial release. It's not really any sort of grand scheme.. it's just we do the version which earns money first ;-)
Thus, there are about 5 distributions to make:
Making all of these and testing all of these doesn't happen overnight. It will be there shortly.
We tend to build the FTP and ISO images after we do the commercial release. It's not really any sort of grand scheme.. it's just we do the version which earns money first ;-)
Thus, there are about 5 distributions to make:
Making all of these and testing all of these doesn't happen overnight. It will be there shortly.
With the new _friendly_ gui install (at least we hope so), X is configured as part of the install.
This isn't so bad, as we use the VESA DDC to discover screen rates, and autodetect videocards, so usually there's nothing to 'configure'. If it manages to break, or if you don't like it, or if you don't even want to think about it, boot from CD#2 and use the familiar Yast1 install, sans-gui. The in-packaging hints suggest this is a possibility if you have trouble.
Best of luck with Linux.
Well, I agree.. these would be pretty impressive... They have some issues though..
Journalling Reiserfs and the tools for reiserfs were to go into SuSE 6.3. Some build issues kept it from being included into the standard kernel (unfortunately), but I expect to see patches to enable these features appear on ftp/web sites soon.
It might actually be in the US version, but I haven't had a chance to look yet.
Of course!
Security may in some cases be upheld by electronic snooping. Therefore, electronic snooping is good!
Sorry, I don't buy it.
I don't welcome the police to search through all my envolopes. I don't carry aroud a pass that makes my wherabouts known at all times.. etc. etc.
It boils down to this: Freedom is more important than Security. If you can't understand that, you deserve neither.
I'm _very_ tempted to download the samba book to our corporate internal webserver. I probably will do this come monday.
I'm less than tickled, however, about the effect this will have on O'Reilly's sales. Do you think our employees will read through it and decide to buy a copy? Or do you think they'll decide not to buy a copy because they don't have to?
I think it _could_ help sales when the book is of sufficiently high quality and density that it is useful after reading it, useful on site, useful when troubleshooting. If it's so much fluff like some companies put out, though, then I can't imagine it would flourish in such an environment.
Somehow I suspect this isn't really us. Simple *bomb bomb bomb* *the president will fall* type stuff is unlikely to really even pass algorithmic muster.
I'm willing to keep pulling for it though... I drop a few phrases here and there in random emails. Maybe I should develop more friends in the Middle East...
f you are saying that OSS could not improve talk+finger because it was a broken concept, implying that OSS can only improve through evolution, then I disagree and again point at the WWW for a counter example. My guess at why the open software community did not improve instant messaging is that no one saw the need.
My points weren't meant to be consistent at all.. I should have unordered them.
I meant in point 5 that open source stuff is having a hard time cloning ICQ because it's broken. No one group has come up with the magic fix.. everyone is fixing it in a different way, etc.
I actually _did_ see the need for improving upon finger and talk, but only because I saw a roughly equivalent app at Farallon they developed but never shipped. It was called "Finger" and it was for the mac. I wanted to make a program for mac, win, unix that was backwards compatable with finger and talk (and write) .. but this was in the days before I really knew how to program.
I think this is an example of something different. I was using finger and talk ten years ago for instant messaging. It worked excellent (finger was much more useful then than today and talk was simple and convenient on a text terminal) and surely it was open source? But commercial messaging systems has taken over because commercial companies rule the desktop market and probably also because of marketing. How much marketing does an initiative such as Gale get?
There are a few little nits I'd like to pick here.
Now I'm at a loss.
You state:
No I'm talking about non RPM'ed code - stuff that isn't nicely packaged... you know... the stuff that's actually useful?
I think you're suggesting that only source-form programs are useful. SuSE does include all packages on the CD in source form except commercial ones, etc. These source form packages are stored in RPMs.
If you simply mean that you have some useful software which is not included in the distribution, and that this software does not build on SuSE, then I am quite surprised. I have built many many packages on SuSE (megaHal, new versions of vim, new versions of mutt, grip, gcd, in-house Wind River software, irc servers and clients.. etc etc) over a long period of time, all without trouble. There was a point (a long time ago) where libcurses wasn't in an ideal spot, but that's about as far as it goes for any trouble I've encountered.
If you truly are encountering lots of packages which refuse to build on SuSE, take a look at what's breaking. I suspect the package maintainer is making some silly assumptions. Example: some tcl software I acquired which had the following line at the start of the software #!/usr/local/bin/tclsh Obviously, this wasn't working as my tclsh was located in /usr/bin..
In any event, please do send criticisms to feedback@suse.de.
SuSE RPM's are great, they work really well, if you don't mind being totally limited to what they offer in RPM format. Same as above..
Please don't moderate this, it adds, nothing to the discusion, I'm merely replying to someone else.
Well, we're _certainly_ off the topic of IPOs. However, we're spot on the discussion you started about SuSE.
I remain curious, however: what are you feeding -nodeps into? I just issued the following command on my Suse 6.2 box: jrodman@Castrovalva:/usr/man >find . -name "*\.[123456789]\.*" -exec zgrep -l -e "-nodeps" {} \; I do have the allman package installed, so this will find the string -nodeps as part of any man page of any package in SuSE. I also spot-checked about 20 configure scripts, not finding this switch present in these either. The following are my findings: ./man8/rpm.8.gz ./allman/man8/rpm.8.gz
PS. How I wish i knew how to see the processor time used by a process and all its children. This grepping in compressed files would be a lovely thing to compare to NT.
ppp is supported. I've called ISPs with the customer on the line to explain to them what is misconfigured in their routers. Of course, it's usually much more simple than that....
As for kppp the reason you had a problem is this: Some dialer software locks the modem device. Some dialer software expects the ppp daemon to lock the modem device. The former is more "proper"... but the dialer developers probably have their own reasons (cross-platform issues perhaps?).
One solution would be for the dialer to always have the responsibility, and either have to run pppd with the 'lock' option, or lock the device itself. This requires custom patches to many dialers. These patches must be maintained, and are in some cases, messy.
Another solution would be to have more than one ppp configuration file. I'm not even going to discuss how messy this is.
The decision was to leave well enough alone, and let the configuration file /etc/ppp/options be set up to work with the majority of dialer software, and for kppp users to comment out the 'lock' line if they wished to use kppp. You see, kppp isn't even our recommended solution. The manual pretty clearly states wvdial is the recommended way to do it, and includes step-by-step instructions. In 6.2, it's even easier, as there's a straightforward configuration screen in YaST called Configure a PPP Network.
Why do we push people away from kppp? For 2 main reasons.
Depending upon my memory, the other problem you could have been running into was kppp simply failing to work at all periodically. This was a kppp bug, and an update to it was available on the FTP site.
toodles.