A little additional info to this quite correct (tho somewhat biassed) overview.
OS/2 LAN Manager from MS and OS/2 LAN Server from IBM both derive from the original IBM PC LAN program. Interestingly however, the smb protocol in its ancient variations that we see in those were published by MS, and not by IBM.
Both share a lot of code, and by 1989, both were available.
The codebases started going their own way at around the time of OS/2 1.3 and Lan Server 1.3, I guess that would be somewhere in 1990/91.
For the record, I was involved in that bit of history as engineer and tester for IBM's OS/2 and Lan products.
> Also associated with this are the increasing number of people who believe that litigation and licensing, not manufacturing/development, are the way to run a sustainable business.
Licensing can be a legitimate and sustainable way to run a business, given that:
1. You actually invented the things you have rights over 2. Your competition would have to invest more in their own research then in buying a license from you.
A good example of a company that has kept itself running this way is Phillips. You do realize that for each and every CD you bought till some 2 years ago, they'd get a tiny bit of money? (they probably still do for those that have one of the official CD logos).
They are the same company that used litigation against others to stop them from messing up the standard, which incidentely worked in the advantage of us, the consumer.
I'd also argue that they do some real work, and try to live from selling the results of their research.
it seems they use a few basic rules to make this work: - If litigation affects the consumer, it has to be in a possitive way else the litigation is a stupid thing to do. - Invent and license instead of buy and relicense.
THat said, there are many companies that seem to do a lot worse job in this, and I assume that those are what you are talking about.
The basic issue here is not even IP related, it is related to this stupid notion that the stock value and investers are more relevant then actual cashflow, proftability and the customer.
I suggest you go talk to a guy formerly known as Prince, he can tell you 'a bit' about this thing called record companies and their stranglehold on artists. Oh, and he has been on both sides of the story, and no, I'm not a big fan of him.
He is however not alone in hs complaints, and situations like the one he found himself in are pretty common, and destroyed many more artists carreers.
It is quite time that IP law is changed. For artists, it would be a major help if the law woudl protect them for example by making it impossible to sign away your rights on your own creation (you should be able to not enforce your rights, but not to give/sell them to someone else). AN artist can still allow a record company to publish their work, but a record company can never claim ownership over the artists work.
> Don't forget about Mono (open source.Net tools). The.Net CLR is an open standard. That's what the Mono folks are working off of. The only downside is that Microsoft has a huge head start in the libraries, widgets, and tools. This makes their solution much more useful (for now).
Please don't forget reading the entire post before replying, I specifically addressed the existance of mono.
At any rate...
There is the potential for patent issues with Mono, just as is the case with open source JAVA development.
Also, the original argument said that SUN was the only provider of JAVA technology while it is not. If GNU, Blackdown, IBM etc are ignored, why not ignore mono?
For completeness' sake, I was not addressing the technical argument, just pointing out that the grandparent was rather ignoring the fact that the situation with regards to choice is very similar, and the single provider issue either exists for both or neither, depending on how much you are bothered by the potential of patent issues. (and one could even argue that in case of JAVA, there are non SUN versions of it that will not have patent issues that you will get to deal with as user/developer, ie the IBM version)
In other words, technically mono is a maybe incomplete but viable alternative, but those exist and have existed for a long time for JAVA as well. Legal status is another thing.
> could not develop commercial quality software on the system since we were at the mercy of Sun for the language, the runtime, and everything els
And a bit later you said:
> Now a virtual machine architecture which supports JIT compiling to different architectures with a consistent set of class libraries and support for multiple different languages including C#, C++, Java, Visual Basic, Cobol, etc... that is useful.
Now the virtual machine and its tools etc still come from one provider, and oen that has a proven track record of screwing over everyone who develops a succesfull product based on its technology instead of from a company that at least has a track record of caring about its customers.
Pleaase tell me how that is better in any way? The multiple langauge support I guess.....
Oh, and you could of course point at mono... but that would mean you'd first have to accept that you can also get java from others then SUN, ie, try IBM, GNU, Blackdown (http://www.blackdown.org/).
> I think a pseudo-random generator continuously re-seeded with true randomness will produce truly random output, not pseudo-random output. Running true randomness through a good mixing function shouldn't destroy it, and neither should taking hashes of parts of the entropy pool.
It depends on a limited number of potentially observable events, all of which interact in a known way. This doesn't make for real randomness.
If this could be used in any practical way for predicting the outcome of the random generator is another question (it is at least extremely difficult I think)
> You said the data you get from/dev/random is pseudo-random. The point of my post was that it's truly random because it comes from truly random events,
See above. If all events would be observable, it is possible to know the state of the random generator. If this is practical depends on the situation, but I can think of situations where it is practical.
There is also the situation that some or many of those events may not occur or will occur in a known patern.
Last but not least, it is still relevant if what you do also results in a well distributed use of all states of the generator over time, else you severely limit the actual entropy that you achieve.
Don't get me wrong btw, what it does is good enough for many uses, but it isn't truely random.
Is this a bit of hair splitting over a definition? well, not entirely. It is good to know that it is good enoug, for now, yet not perfect by any means, and may not be usable for all applications right now either. (think embedded devices that need strogn security and have very little 'random' events to use for this, or where restricting physical access is impossible)
> Cryptographic strength is all about predictability, but for simulations, true random numbers matter because you don't want to skew things with any possible patterns.
True. We were however talking about cryptography and using/dev/random for generating a good key for wpa. Predictability is everything there. That said, you still don't want any weird paterns to show up, they are bad for preventing predictability.
> I used Linux as an example because I know how it works, not purely to push it. I guess I can see how you might have gotten that impression, though, so no hard feelings.
Ok, then my impression was wrong there, sorry. Oh, and your explanation is technically correct for all I know, but this is a case of 'good enough', not of 'scientifically correct' randomness.
At any rate.. the point of my original post was that not all Unix like systems have good sources for random numbers, others have good to excelent support for it. The later include systems like Linux, OpenBSD, NetBSD and FreeBSD.
> On Linux, that's wrong./dev/urandom returns very high quality pseudo-random at _worst_./dev/random never resorts to mere pseudo randomness, and read(2)s on it block until the kernel has accumulated enough entropy in its pool. (yes, Linux maintains an entropy pool which it seeds from random events so there is some true randomness waiting for programs like gnupg or statistical simulations that need it.)
Blahblahblah.
1. the point of my post was to point out that you should verify that your random generator has a good enough entropy source, and if you had bothered to read my post a bit more carefully, you would have seen that I am aware of the fact that Linux does a decent job at this.
2. You ensure randomness in the entropy pool, and thereby in the state of the random generator. The generator itself however is still pseudo random.
3. Sorry if I sound annoyed here, but what was the point of your post other then trying to push a specific system?
> Actually, Nokia and others, design around the battery. Yes, they have some say, but they cannot say give me a battery that has three times the capacity and weighs half as much. That's a limitation of battery design issue, not an availabiltiy or customization issue.
They are bound to what is physically possible, but when they pay for it, they can definitely also get better batteries developed. Mobile phones and laptops are the main reasons why we are no longer stuck with nicads as the only viable recharchable dry batteries.
> The camera uses little/no power when not in use. The major power consumers in a mobile phone are the display and the RF transmitter. Both are essential to the basic performance of the phone.
The 'big' color displays are mostly a 'must have' due to many other features of the phones beign unusable without them.
For simple phone operation, a monochrome screen that can display 12x5 chars of text will do fine and will use a lot less power then the color screens in most modern phones.
> Also, don't make the claim that there's a marketable number of people who would trade increased battery life for a less clear or a less functional display. If such a market existed, the mfgs would be scrambling to fill it.
They do not fill in tha market for a reason, but that reason is not that the market does not exist.
The reason is that that amrket has a very low replacement rate and that makes the demand from that market a lot lower.
People are quite prepared to trade features for longer battery life, but not if the phone ebcomes 3x as expensive also to make up for the lower replacement rate.
> So, no, for the most part, it is not in the control of the phone mfgs. It is a combination of the physical limitations in current battery design coupled with consume demand.
Consumer demands are pretty much marketing driven, and battery makers are also driven by demand, so yes, phone manufacterors do have quite an influence here, they are just not the only ones with a say in it.
> Ah, but is there a URL which doesn't give you either retarded Flash adverts or (depending on your tolerance for crap software) a popup message demanding you install stuff to read slashdot?
Yeah. Ever since the majority of ads here is flash based, the ad servers Slashdot uses made it onto my blacklist.
It is funny really. I did tolelrate the ads here for quite soem time sunce they were for a long time non-intrusive and somewhat targetted. Stick in flash and I just block the adserver (and yeah, I do have a flash player installed, and click to play also, but it is still annoying as hell)
So hello Slashpeople, if you read this, GET RID OF FLASH ADS!!!!! When you do and post about it, I'll unlist the ad servers you use.
> just generate a key from/dev/urandom on nix. doesn't get any more random than that
Maybe you are talking about a specific implementation here (Linux I bet) and detaisl are sightly different between different unix like systems.../dev/urandom is not random at all, it is pseudo-random at best.
The basic issue is that as soon as you think up a process that generates numbers in a way that you can describe mathematically, you also end up with a process uncapable of generating real randomness.
You can get most aspects of randomness, but what you won't get, and that is the most important part for encryption, is unpredictability.
How predictable things are depends for a bit on the algorithm that you use, and for a large part on the abbility to deduct the current state of the 'random generator'. If those 2 are known, the next number your random generator will produce can also be known.
This is why it is so important to have a good entropy source, it makes it virtually impossible to guess at the state of the generator.
What is more important with digicam pictures is the actual sharpness and contrast of the picture. You may find that at times converting to greyscale helps a lot while in other cases it makes ocr near impossible etc..
Those were pretty pictures of cars and keyboards. Troll mode off, but who cares about subtle gradations of color in a telephone? I'd rather know about:
* How much memory do they have for images?
Why would you need that memory when it doesn't take decent pictures to begin with?
* How long do the batteries last?
Good question.
* Do they have a firewire port, or just lame USB 1.0?
and most importantly
* Are they decent phones
Hmm, USB 2.0 would do as well, it is just a lot more universal (ie, there are A LOT more people who have usb then who have firewire)
ANd with regards to decent phones.. I'm afraid that is no longer significant nowadays..
> not something directly under most mfgs control as they don't design batteries, they buy them from others
1. I'm pretty sure that if Nokia wants a few milion batteries with certain specifications, battery manufacterors will gladly comply, so your argument does not hold.
2. The amount of features in modern phones requires them to be more powerfull and contain more electronics and as a result use more power then needed for simple phone and text messaging functions.
So yes, it is quite in the control of phone manufacterors.
> (although some never grow out of it, like Micheal Moore). Basicly irrationally doing activism for activism sakes (like GPL advocacy) without figuring that their own actions are irresponsible, damaging, and stupid.
Ah, you mean like typical anti Moore activism among American republicans?
Wel, get an external d/a converter (and a soundcard with spdif out) so you can at least get the analog sound away from that source of interference that the average computer is.
> Soemtimes a state has to train its citizen militia to shoot humans.
Maybe, but if you just go look around, cirizen melitia cause way more problems then they ever solved.
There is the often used arguments of melitia beign protection against tyranic government, but just go look at places where melitia actually fight the local government, and now look at tyranic governments that were overthrown in the last 5 decades. You will find that whenever melitia played a role in overthrowing such a government, the resuklt was a state ogf civil wwar for years if not decades to come.
Sorry, but if you want this argument to hold, you will have to come up with something better then just stating it. FOr now the argument looks at best doubtfull, and without any better substance, it looks pretty invalid.
> The intention of the DeCSS itself is still to copy, the intention of the user may be to watch soemthing indeed.
No, the intention of DeCSS is to read data, and on its own it is not capable of more then that. If you use that for copying or viewing is an entirely seperate issue.
THat is practise for either hunting or shooting humans. According to soem it is also fun to do.
> What about hunting?
Valid use of firearms. No need for handguns and automatic weapons when hunting tho.
> What about nonlethal uses of a firearm on people, such as aiming a handgun at an attacker's shoulder to make him drop the gun that he's trying to use lethally, as Holly Hunter demonstrates on a shooting range in the beginning of the movie Copycat ?
That would make for threatening to kill with a firearm. The intention of the weapon itself is still to kill, the intention of the user may be to stop soemone else indeed.
You might want to realize however that in a society where firearms are commonplace, an attacker is a lot more likely to use one against you because an attacker is a lot mroe likely to expect you to have one. I prefer fighting an attacker that doesn't have one, and I stand a much betetr channce at having it end good for me also.
> So in essence you're doubling/tripling the price you could pay for the benefit od a preinstalled OS, i'm sorry but as much as my ego would love to say otherwise 4 hours of my time is not worth ~£700... I'm not a PC zealot, I love the PowerPC architecture but macs are simply overpriced for what you get... you pay for the branding and nothing more.
Quite true when you build something for yourself. If you are a company you also have to calculate in a bit of a proffit margin and a reservation for warranty, not to mention the normal overhead costs.
Apple is expensive and you pay in part for the name, but the difference is not as big as it seems at first glance.
Re:does fbsd have good framebuffer console?
on
FreeBSD 5.3 RC2 Released
·
· Score: 2, Informative
> i'd prefer a "real" graphics mode (like Linux fbdev) because that way i can use image/video software like mplayer/fbi/links2 on the console (but maybe it's ok to limp along with svgalib for now...)
Hmm, that seems to work on a radeon 9200 here when using xvidx driver, but yeah, using background graphics would be a reason to want graphics mode.
Eventho xvidx manages to play a movie as background of a text mode console, it isn't without flaws (scaling does not always work properly, and cpu cost is rather high when compared to using xvideo for example, not to mention the impact on responsiveness of the machine)
I prefer the speed and low resource use of a character mode console, tho that seems mostly relevant on low-end hardware, and changes as soon as you want to use something like xvidx. I found I'm usually better off using a very minimal x-windows setup for running graphics mode programs in such cases on FreeBSD.
> i'm sure my video cards have vesa1.2, they're not that old. here's 'lspci' output: 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a) 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630 GUI Accelerator+3D (rev 31)
Hmm, from what I can tell both should work indeed, just ensure you have the VESA module loaded (add vesa_load="YES" to/boot/loader.conf) and ensure that you have softfonts loaded (see the 'configure' menu of the installer, goto 'Console' and from there got 'Fonts' and select the font(s) suitable for your language)
You should now be able to do a vidcontrol 132x43 and such.
Btw, the 800x600 pixel mode that FreeBSD's syscons driver supports is actually intended for forcing certain laptops into graphics mode so X can properly use it later. I happen to use it to get a console on tv-out for a pc I use as media center. Supporting hires screens for text doesn't seem part of the plan for it. Interestingly, vidcontrol on my system lists quite a few graphics modes beyond 800x600, but refuses to consider them as valid when trying to switch to them.
> I think Broadcom cards work now under DragonFly. I don't know about multiple audio cards. In both cases, it's worth asking on one of the DragonFly mailing lists (kernel@dragonflybsd.org or users@dragonflybsd.org) - if they aren't supported, there's folks who may be able to work on it.
Well, good to hear that it is developing well in that area also.
> As for accelerated GL - FreeBSD nvidia drivers work through a port override, and anything else that XFree86/X.org works with should go fine.
Hmm, means it will work on at least oen machien here with accelerated opengl, good to know. Is dri available for the opensource opengl drivers for older ati and matrox hardware also?
> There's a lot of VFS work going on right now,
Yeah, read about it on the Dragonfly website.
> so if this is for work machines, it may be worth waiting... > but it will also be worth evaluating.
Yep. current lack of a modern x86 machine that is available for this is why I don't have it running right now. THe x86 hardware that I have is used for work and somewhat serious personal stuff. Most 'playing' with operating systems is on things like slightly older sgi and sun hardware here for now.
Definitely something I will keep an eye on tho, and as said, when it supports enough of the hardware that I use daily, it is likely to find a spot on a machine here. Good to kmow that it is closer to that point then I thought.
> Disclaimer: I work on DragonFly, so of course I think it's great.
Hehe, well, no problem there.
Also pls note that my original comemnt was not to say that Draginfly is not interesting, but to point at the thread hijacking by some of its supporters that imho is rather counter productive (and I hoped to do so in a somewhat funny way, which oh wonders seems to have been understood by at least one moderator)
At any rate, good luck with the system, and I will definitely keep an eye on how it is developing.
> This 5.3 release is full of bugs and is slow too.
It certainly has some bugs. Regarding slow, it is far from slow for what I happen to do with it, but it might be for your case.
> It still does not release the Big Giant Lock like it was promised a year ago.
It does for some and not for other cases. It is definitely not free from giant locks for now.
> It looks like it's time to give the DragonFly branch of FreeBSD 4 a try.
I find Dragonfly very interesting but at the moment it is not usable for production for me for the simple reason that it lacks support for hardware that I have and use (and so does FreeBSD 4.x), so little choice there (alternative woudl be to run Linux on that hardware)
What hardware?
Broadcom gigabit ethernet chipset (yea, I know its crappy, but it is on many mid/lowcost systemboards, and it does work well enough for most workstation purposes)
Any graphics hardware with accelerated opengl that actually performs somewhat better then software rendering.
Support for multiple audio cards, preferably with virtual audio channels.
Now, those may not be features you require, fine for you. I do happen to need them, so I will pcik a platform that supports them.
If/when Dragonfly happens to support either smp on a hypersparc machine or most of the hardware that I happen to use every day, it will have a good chance of finding a spot on a machine here.
I wonder about your post tho. Commenting on the scheduler and locking problems is justified tho hardly new, but do you think you are doing anyone a favor by acting similar to that HawkinsOS guy? (ie, hijack each and every FreeBSD related thread anywhere to promote your system of choice while re-iterating the same argument over and over)
Slashdot Mirror
A little additional info to this quite correct (tho somewhat biassed) overview.
OS/2 LAN Manager from MS and OS/2 LAN Server from IBM both derive from the original IBM PC LAN program. Interestingly however, the smb protocol in its ancient variations that we see in those were published by MS, and not by IBM.
Both share a lot of code, and by 1989, both were available.
The codebases started going their own way at around the time of OS/2 1.3 and Lan Server 1.3, I guess that would be somewhere in 1990/91.
For the record, I was involved in that bit of history as engineer and tester for IBM's OS/2 and Lan products.
I really suggest you read more carefully. I mentioned mono explicitly in my post, so yes, I am aware that it exists.
> Also associated with this are the increasing number of people who believe that litigation and licensing, not manufacturing/development, are the way to run a sustainable business.
Licensing can be a legitimate and sustainable way to run a business, given that:
1. You actually invented the things you have rights over
2. Your competition would have to invest more in their own research then in buying a license from you.
A good example of a company that has kept itself running this way is Phillips. You do realize that for each and every CD you bought till some 2 years ago, they'd get a tiny bit of money? (they probably still do for those that have one of the official CD logos).
They are the same company that used litigation against others to stop them from messing up the standard, which incidentely worked in the advantage of us, the consumer.
I'd also argue that they do some real work, and try to live from selling the results of their research.
it seems they use a few basic rules to make this work:
- If litigation affects the consumer, it has to be in a possitive way else the litigation is a stupid thing to do.
- Invent and license instead of buy and relicense.
THat said, there are many companies that seem to do a lot worse job in this, and I assume that those are what you are talking about.
The basic issue here is not even IP related, it is related to this stupid notion that the stock value and investers are more relevant then actual cashflow, proftability and the customer.
I suggest you go talk to a guy formerly known as Prince, he can tell you 'a bit' about this thing called record companies and their stranglehold on artists. Oh, and he has been on both sides of the story, and no, I'm not a big fan of him.
He is however not alone in hs complaints, and situations like the one he found himself in are pretty common, and destroyed many more artists carreers.
It is quite time that IP law is changed. For artists, it would be a major help if the law woudl protect them for example by making it impossible to sign away your rights on your own creation (you should be able to not enforce your rights, but not to give/sell them to someone else). AN artist can still allow a record company to publish their work, but a record company can never claim ownership over the artists work.
> Don't forget about Mono (open source .Net tools). The .Net CLR is an open standard. That's what the Mono folks are working off of. The only downside is that Microsoft has a huge head start in the libraries, widgets, and tools. This makes their solution much more useful (for now).
Please don't forget reading the entire post before replying, I specifically addressed the existance of mono.
At any rate...
There is the potential for patent issues with Mono, just as is the case with open source JAVA development.
Also, the original argument said that SUN was the only provider of JAVA technology while it is not. If GNU, Blackdown, IBM etc are ignored, why not ignore mono?
For completeness' sake, I was not addressing the technical argument, just pointing out that the grandparent was rather ignoring the fact that the situation with regards to choice is very similar, and the single provider issue either exists for both or neither, depending on how much you are bothered by the potential of patent issues. (and one could even argue that in case of JAVA, there are non SUN versions of it that will not have patent issues that you will get to deal with as user/developer, ie the IBM version)
In other words, technically mono is a maybe incomplete but viable alternative, but those exist and have existed for a long time for JAVA as well.
Legal status is another thing.
You said:
> could not develop commercial quality software on the system since we were at the mercy of Sun for the language, the runtime, and everything els
And a bit later you said:
> Now a virtual machine architecture which supports JIT compiling to different architectures with a consistent set of class libraries and support for multiple different languages including C#, C++, Java, Visual Basic, Cobol, etc... that is useful.
Now the virtual machine and its tools etc still come from one provider, and oen that has a proven track record of screwing over everyone who develops a succesfull product based on its technology instead of from a company that at least has a track record of caring about its customers.
Pleaase tell me how that is better in any way? The multiple langauge support I guess.....
Oh, and you could of course point at mono... but that would mean you'd first have to accept that you can also get java from others then SUN, ie, try IBM, GNU, Blackdown (http://www.blackdown.org/).
> I think a pseudo-random generator continuously re-seeded with true randomness will produce truly random output, not pseudo-random output. Running true randomness through a good mixing function shouldn't destroy it, and neither should taking hashes of parts of the entropy pool.
/dev/random is pseudo-random. The point of my post was that it's truly random because it comes from truly random events,
/dev/random for generating a good key for wpa. Predictability is everything there. That said, you still don't want any weird paterns to show up, they are bad for preventing predictability.
It depends on a limited number of potentially observable events, all of which interact in a known way. This doesn't make for real randomness.
If this could be used in any practical way for predicting the outcome of the random generator is another question (it is at least extremely difficult I think)
> You said the data you get from
See above. If all events would be observable, it is possible to know the state of the random generator. If this is practical depends on the situation, but I can think of situations where it is practical.
There is also the situation that some or many of those events may not occur or will occur in a known patern.
Last but not least, it is still relevant if what you do also results in a well distributed use of all states of the generator over time, else you severely limit the actual entropy that you achieve.
Don't get me wrong btw, what it does is good enough for many uses, but it isn't truely random.
Is this a bit of hair splitting over a definition? well, not entirely. It is good to know that it is good enoug, for now, yet not perfect by any means, and may not be usable for all applications right now either. (think embedded devices that need strogn security and have very little 'random' events to use for this, or where restricting physical access is impossible)
> Cryptographic strength is all about predictability, but for simulations, true random numbers matter because you don't want to skew things with any possible patterns.
True. We were however talking about cryptography and using
> I used Linux as an example because I know how it works, not purely to push it. I guess I can see how you might have gotten that impression, though, so no hard feelings.
Ok, then my impression was wrong there, sorry. Oh, and your explanation is technically correct for all I know, but this is a case of 'good enough', not of 'scientifically correct' randomness.
At any rate.. the point of my original post was that not all Unix like systems have good sources for random numbers, others have good to excelent support for it. The later include systems like Linux, OpenBSD, NetBSD and FreeBSD.
> On Linux, that's wrong. /dev/urandom returns very high quality pseudo-random at _worst_. /dev/random never resorts to mere pseudo randomness, and read(2)s on it block until the kernel has accumulated enough entropy in its pool. (yes, Linux maintains an entropy pool which it seeds from random events so there is some true randomness waiting for programs like gnupg or statistical simulations that need it.)
Blahblahblah.
1. the point of my post was to point out that you should verify that your random generator has a good enough entropy source, and if you had bothered to read my post a bit more carefully, you would have seen that I am aware of the fact that Linux does a decent job at this.
2. You ensure randomness in the entropy pool, and thereby in the state of the random generator. The generator itself however is still pseudo random.
3. Sorry if I sound annoyed here, but what was the point of your post other then trying to push a specific system?
> Same situation :) FreeBSD does it with Linux emulation.
I know... I have been building them from ports for years, just didn't look at 1.5/5 yet.
> gcc has to do the same thing
Well, only partially.
What GCC needs is an ansi C compiler (and at least for 2.9x and earlier, a K&R compiler would do)
Those are available from many sources.
I have built gcc (2.95) on HPUX with help from the K&R C compiler that HPUX comes with by default.
I still have to see jdk14 build with anything that is not a SUN or IBM jvm.
I haven't checked for this version yet, but with 1.4 and earlier, building from source required having a working jvm.. kindof a chicken egg problem :P
> Actually, Nokia and others, design around the battery. Yes, they have some say, but they cannot say give me a battery that has three times the capacity and weighs half as much. That's a limitation of battery design issue, not an availabiltiy or customization issue.
They are bound to what is physically possible, but when they pay for it, they can definitely also get better batteries developed. Mobile phones and laptops are the main reasons why we are no longer stuck with nicads as the only viable recharchable dry batteries.
> The camera uses little/no power when not in use. The major power consumers in a mobile phone are the display and the RF transmitter. Both are essential to the basic performance of the phone.
The 'big' color displays are mostly a 'must have' due to many other features of the phones beign unusable without them.
For simple phone operation, a monochrome screen that can display 12x5 chars of text will do fine and will use a lot less power then the color screens in most modern phones.
> Also, don't make the claim that there's a marketable number of people who would trade increased battery life for a less clear or a less functional display. If such a market existed, the mfgs would be scrambling to fill it.
They do not fill in tha market for a reason, but that reason is not that the market does not exist.
The reason is that that amrket has a very low replacement rate and that makes the demand from that market a lot lower.
People are quite prepared to trade features for longer battery life, but not if the phone ebcomes 3x as expensive also to make up for the lower replacement rate.
> So, no, for the most part, it is not in the control of the phone mfgs. It is a combination of the physical limitations in current battery design coupled with consume demand.
Consumer demands are pretty much marketing driven, and battery makers are also driven by demand, so yes, phone manufacterors do have quite an influence here, they are just not the only ones with a say in it.
> Ah, but is there a URL which doesn't give you either retarded Flash adverts or (depending on your tolerance for crap software) a popup message demanding you install stuff to read slashdot?
Yeah. Ever since the majority of ads here is flash based, the ad servers Slashdot uses made it onto my blacklist.
It is funny really. I did tolelrate the ads here for quite soem time sunce they were for a long time non-intrusive and somewhat targetted. Stick in flash and I just block the adserver (and yeah, I do have a flash player installed, and click to play also, but it is still annoying as hell)
So hello Slashpeople, if you read this, GET RID OF FLASH ADS!!!!! When you do and post about it, I'll unlist the ad servers you use.
> just generate a key from /dev/urandom on nix. doesn't get any more random than that
/dev/urandom is not random at all, it is pseudo-random at best.
Maybe you are talking about a specific implementation here (Linux I bet) and detaisl are sightly different between different unix like systems...
The basic issue is that as soon as you think up a process that generates numbers in a way that you can describe mathematically, you also end up with a process uncapable of generating real randomness.
You can get most aspects of randomness, but what you won't get, and that is the most important part for encryption, is unpredictability.
How predictable things are depends for a bit on the algorithm that you use, and for a large part on the abbility to deduct the current state of the 'random generator'. If those 2 are known, the next number your random generator will produce can also be known.
This is why it is so important to have a good entropy source, it makes it virtually impossible to guess at the state of the generator.
150dpi should really do for OCR.
What is more important with digicam pictures is the actual sharpness and contrast of the picture. You may find that at times converting to greyscale helps a lot while in other cases it makes ocr near impossible etc..
Why would you need that memory when it doesn't take decent pictures to begin with?
Good question.
Hmm, USB 2.0 would do as well, it is just a lot more universal (ie, there are A LOT more people who have usb then who have firewire)
ANd with regards to decent phones.. I'm afraid that is no longer significant nowadays..
> not something directly under most mfgs control as they don't design batteries, they buy them from others
1. I'm pretty sure that if Nokia wants a few milion batteries with certain specifications, battery manufacterors will gladly comply, so your argument does not hold.
2. The amount of features in modern phones requires them to be more powerfull and contain more electronics and as a result use more power then needed for simple phone and text messaging functions.
So yes, it is quite in the control of phone manufacterors.
> (although some never grow out of it, like Micheal Moore). Basicly irrationally doing activism for activism sakes (like GPL advocacy) without figuring that their own actions are irresponsible, damaging, and stupid.
Ah, you mean like typical anti Moore activism among American republicans?
Gotta love those pot-kettle posts.
That is all pretty obvious and thereby fails one of the primary checks that should have been done by the USPTO.
Wel, get an external d/a converter (and a soundcard with spdif out) so you can at least get the analog sound away from that source of interference that the average computer is.
> Soemtimes a state has to train its citizen militia to shoot humans.
Maybe, but if you just go look around, cirizen melitia cause way more problems then they ever solved.
There is the often used arguments of melitia beign protection against tyranic government, but just go look at places where melitia actually fight the local government, and now look at tyranic governments that were overthrown in the last 5 decades. You will find that whenever melitia played a role in overthrowing such a government, the resuklt was a state ogf civil wwar for years if not decades to come.
Sorry, but if you want this argument to hold, you will have to come up with something better then just stating it. FOr now the argument looks at best doubtfull, and without any better substance, it looks pretty invalid.
> The intention of the DeCSS itself is still to copy, the intention of the user may be to watch soemthing indeed.
No, the intention of DeCSS is to read data, and on its own it is not capable of more then that. If you use that for copying or viewing is an entirely seperate issue.
> What about target shooting?
THat is practise for either hunting or shooting humans. According to soem it is also fun to do.
> What about hunting?
Valid use of firearms. No need for handguns and automatic weapons when hunting tho.
> What about nonlethal uses of a firearm on people, such as aiming a handgun at an attacker's shoulder to make him drop the gun that he's trying to use lethally, as Holly Hunter demonstrates on a shooting range in the beginning of the movie Copycat ?
That would make for threatening to kill with a firearm. The intention of the weapon itself is still to kill, the intention of the user may be to stop soemone else indeed.
You might want to realize however that in a society where firearms are commonplace, an attacker is a lot more likely to use one against you because an attacker is a lot mroe likely to expect you to have one. I prefer fighting an attacker that doesn't have one, and I stand a much betetr channce at having it end good for me also.
> So in essence you're doubling/tripling the price you could pay for the benefit od a preinstalled OS, i'm sorry but as much as my ego would love to say otherwise 4 hours of my time is not worth ~£700... I'm not a PC zealot, I love the PowerPC architecture but macs are simply overpriced for what you get... you pay for the branding and nothing more.
Quite true when you build something for yourself. If you are a company you also have to calculate in a bit of a proffit margin and a reservation for warranty, not to mention the normal overhead costs.
Apple is expensive and you pay in part for the name, but the difference is not as big as it seems at first glance.
> i'd prefer a "real" graphics mode (like Linux fbdev) because that way i can use image/video software like mplayer/fbi/links2 on the console (but maybe it's ok to limp along with svgalib for now...)
/boot/loader.conf) and ensure that you have softfonts loaded (see the 'configure' menu of the installer, goto 'Console' and from there got 'Fonts' and select the font(s) suitable for your language)
Hmm, that seems to work on a radeon 9200 here when using xvidx driver, but yeah, using background graphics would be a reason to want graphics mode.
Eventho xvidx manages to play a movie as background of a text mode console, it isn't without flaws (scaling does not always work properly, and cpu cost is rather high when compared to using xvideo for example, not to mention the impact on responsiveness of the machine)
I prefer the speed and low resource use of a character mode console, tho that seems mostly relevant on low-end hardware, and changes as soon as you want to use something like xvidx. I found I'm usually better off using a very minimal x-windows setup for running graphics mode programs in such cases on FreeBSD.
> i'm sure my video cards have vesa1.2, they're not that old. here's 'lspci' output:
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630 GUI Accelerator+3D (rev 31)
Hmm, from what I can tell both should work indeed, just ensure you have the VESA module loaded (add vesa_load="YES" to
You should now be able to do a vidcontrol 132x43 and such.
Btw, the 800x600 pixel mode that FreeBSD's syscons driver supports is actually intended for forcing certain laptops into graphics mode so X can properly use it later. I happen to use it to get a console on tv-out for a pc I use as media center. Supporting hires screens for text doesn't seem part of the plan for it. Interestingly, vidcontrol on my system lists quite a few graphics modes beyond 800x600, but refuses to consider them as valid when trying to switch to them.
> I think Broadcom cards work now under DragonFly. I don't know about multiple audio cards. In both cases, it's worth asking on one of the DragonFly mailing lists (kernel@dragonflybsd.org or users@dragonflybsd.org) - if they aren't supported, there's folks who may be able to work on it.
Well, good to hear that it is developing well in that area also.
> As for accelerated GL - FreeBSD nvidia drivers work through a port override, and anything else that XFree86/X.org works with should go fine.
Hmm, means it will work on at least oen machien here with accelerated opengl, good to know. Is dri available for the opensource opengl drivers for older ati and matrox hardware also?
> There's a lot of VFS work going on right now,
Yeah, read about it on the Dragonfly website.
> so if this is for work machines, it may be worth waiting...
> but it will also be worth evaluating.
Yep. current lack of a modern x86 machine that is available for this is why I don't have it running right now. THe x86 hardware that I have is used for work and somewhat serious personal stuff. Most 'playing' with operating systems is on things like slightly older sgi and sun hardware here for now.
Definitely something I will keep an eye on tho, and as said, when it supports enough of the hardware that I use daily, it is likely to find a spot on a machine here. Good to kmow that it is closer to that point then I thought.
> Disclaimer: I work on DragonFly, so of course I think it's great.
Hehe, well, no problem there.
Also pls note that my original comemnt was not to say that Draginfly is not interesting, but to point at the thread hijacking by some of its supporters that imho is rather counter productive (and I hoped to do so in a somewhat funny way, which oh wonders seems to have been understood by at least one moderator)
At any rate, good luck with the system, and I will definitely keep an eye on how it is developing.
> This 5.3 release is full of bugs and is slow too.
It certainly has some bugs. Regarding slow, it is far from slow for what I happen to do with it, but it might be for your case.
> It still does not release the Big Giant Lock like it was promised a year ago.
It does for some and not for other cases. It is definitely not free from giant locks for now.
> It looks like it's time to give the DragonFly branch of FreeBSD 4 a try.
I find Dragonfly very interesting but at the moment it is not usable for production for me for the simple reason that it lacks support for hardware that I have and use (and so does FreeBSD 4.x), so little choice there (alternative woudl be to run Linux on that hardware)
What hardware?
Broadcom gigabit ethernet chipset (yea, I know its crappy, but it is on many mid/lowcost systemboards, and it does work well enough for most workstation purposes)
Any graphics hardware with accelerated opengl that actually performs somewhat better then software rendering.
Support for multiple audio cards, preferably with virtual audio channels.
Now, those may not be features you require, fine for you. I do happen to need them, so I will pcik a platform that supports them.
If/when Dragonfly happens to support either smp on a hypersparc machine or most of the hardware that I happen to use every day, it will have a good chance of finding a spot on a machine here.
I wonder about your post tho. Commenting on the scheduler and locking problems is justified tho hardly new, but do you think you are doing anyone a favor by acting similar to that HawkinsOS guy? (ie, hijack each and every FreeBSD related thread anywhere to promote your system of choice while re-iterating the same argument over and over)