AFAIK, there is one non native English speakers among the non-elected. Mind you, there is a healthy number of non-americans among elected and non-elected.
The results, to me, seems reflect how active the candidates have been in the FreeBSD technical mailing lists and commit logs, and how important their contributions have been.
And I'd wager at least one of the non-elected would have been elected had he not spent some months away from FreeBSD in this past year.
So it comes down to lack of non-native english speakers candidates. Since any committer was allowed to become a candidate, and FreeBSD has a good number of committers who are non-native english speakers, I have to wonder why that was so.
There obviously is no market pressure on the few big players (aka price fixing?), and as
the judge in the Napster case astutely noted "why isn't there any singles like 45s in the old days?" (because it
costs the same to do a single !!!)
There are singles. They are wildly popular in Japan, and I have a good amount of them. Next non-sense, please.
When you compile Java into native binaries, you _still_ append the JVM to these binaries. What do you think makes memory garbage collection in Java? Where do you think these processes will go when you generate the native binaries?
You are not getting rid of the problem, you are just hiding it. All these "ugly things" prone to errors are simply _hidden_ inside the JVM. But they are _still_ needed, and _still_ used. And written in C.:-)
Heh. Java needs a JVM to run. If you write the JVM in Java, that JVM would need a JVM to run on. Ie, you'd have a JVM written in Java running over a JVM written in C.:-)
This means nothing. Being scalable means that performance with 30 processors is about the double of performance with 15 processors, and so forth. If this 31 processors machine, running Linux, can deliver more juice than a machine with 8 processors, I'd be surprised.
Yes, it would seem the law makes it illegal to offer Internet access to children. So... sue libraries to make it so. That's what's needed to drive the point: escalate it to it's ridicule consequences.
The BSD ports system does that. Well, it actually uses variables that can be overridden to determine stuff such as where things are getting installed, but, by default, everything gets installed in standarized places. See man hierarchy.
The plan is using the same ports tree to ALL BSD.
Frankly, there level of cluelessness of Debian people about ports/package is mighty impressive. There is only _one_ thing that Debian does in an automated fashion which ports/package doesn't which is upgrade.
Yeah, Not Invented Here syndronme is a drag. I mean, why did they have to invent rpm and dpkg instead of using FreeBSD ports/package system?
Well, the OTHER BSDs did not make this mistake, and adopted the ports/package (though ports is called packages on NetBSD, since they already used the word "ports" for something else). But since they are different, the _content_ of the ports tree is different. You can't use the FreeBSD one on OpenBSD. That's what they are unifying.
Well, now, that's an interesting piece of software. Thing is... autoconf works for the platforms the author configured it too. Lately, it is an automated source configuration system that generates the appropriate header files and defines to compile stuff under Linux.:-)
Well, 3.4 and 3.5 and *not* being worked on. 3.x, 4.x and 5.x are.
FreeBSD uses CVS to manage source code. With CVS, every time you make a change to a file you wish to integrate, a new "version" of that file is created. You can retrieve any particular version of a file, generate diffs between versions, etc.
Now, the versions are numbered in ascending order, as you would expect, but multiple "branches" may exist. For instance, "current" is the HEAD branch, 4.x is RELENG_4, 3.x is RELENG_3,and so on. Each branch progresses independently. One can ask for the latest file of a particular branch. That's what 3.x-stable, 4.x-stable and 5.x-current are.
A release, such as 3.4-RELEASE, 3.5-RELEASE, 4.0-RELEASE or 4.1-RELEASE, is a point in time. We mark the latest version of all files in a particular with a tag, such as RELENG_4_0_0_RELEASE, and those files/version with that tag are the ones that compose a particular release.
Now, why work on more than one branch at the same time? First, let's see how work is done on FreeBSD.
There are different origins to the source code found in FreeBSD. Some of it are externally maintained programs, such as sendmail and bind. These are imported from time to time, when a particular version is deemed stable enough.
Other programs are also developed externally to FreeBSD, but their developers are also FreeBSD committers. These are usually updated on a regular basis. It's the case particularly of some device drivers, shared by FreeBSD and Linux or one of the other BSD. It is also the case of code being developed by companies who sell solutions using FreeBSD, and have internal patches.
Finally, there are the programs "local" to FreeBSD, who are constantly updated. The actual development is still done out of the FreeBSD tree, and only updated at points where the code is functional.
These updates are usually done on the HEAD branch, or current, which, right now, is known as 5.x-current. Because of the very nature of software development, this results in serious bugs from time to time, and even break down of the build process. That's why people should stay away from -current, generally speaking.
As the code matures, and particular versions are deemed safe, they are merged back on the latest stable branch, 4.x-stable. This includes new device drivers and bug fixes. New features are also added in some cases, but the general rule is to leave new stuff out of stable.
Now, when a current reaches a certain point, a new stable branch is created out of it. This branch is identical to current at that point in time, though it quickly starts to diverge. But since it WAS a current up to that time, the new stable isn't *rock* stable previous stable branches. This is the.0 syndronme.
Because of that, serious users avoid the.0 release, some avoid the.1 release, and some claim to avoid anything below.5, even.
These users expect their very reliable stable branch to continue to receive bug fixes and, particularly, security fixes. Thus, we, for a while, merge fixes to the latest two stable branches. Right now, 4.x and 3.x.
It's worth mention, though, that 3.x is at the end of it's life time, and won't be receiving many patches anymore.
Still, some people DO merge fixes all the way to 2.2.x. Usually, they have their own applications still based on such older versions, and like to keep them up to date.:-)
They also have a whole different perspective. See, for instance, Kareshi Kanojo no Jijyo, which was aimed at high/junior high girls, and aired at 6pm (5:30pm through 7:30pm is the typical time for most cartoons). Their main characters had, , sex!:-) Not that there was an actual sex scene, but there wasn't any doubt about the event either.
In Japan, they make anime for all ages. They have kids stuff, teen stuff, and adult stuff (both sexual content and non-sexual content).
If this is the series I saw last year, it is most definitely NOT similar to BubbleGum Crisis in any way. Though they share the same universe, AD Police has a very dark feeling to it. Likewise, the art is completely different.
Actually, I meant all OSS OS . Since gcc is the only OSS compiler out there with IA64 support, and the OSS OS I know of all depend on some special gcc features anyway,... <shrug>
I'm pretty sure most of the corporations out there writing closed source software for Linux are using gcc, because that's the only Real compiler available for Linux. That is, until Borland decides to show up.
One problem with GCC back-end is that the intermediate language sucks horribly. It's completely inadequate for expressing parallelism, ordering and dependence issues.
For this reason, all OSS will suck very, very badly on IA64, btw.:-(
Err, the what the program must do can be defined in declarative language, where you specify assertions and invariants that must be true in every execution of the program (actually, temporal logics statements).
An automatic formal correctness validation program will then verify these against some code that describes _how_ to achieve those results.
For instance, check Spin/Promela, and the very simple Mutual Exclusion examples. Declaring what a Mutual Exclusion algorithm must do is simple, and very different from actually writing a program to do it.
The energy density for either ethanol or gasoline is incorrect. Brazilian ethanol-based cars had efficiency only 30-50% inferior to gasoline (range -- power was always much more a function of the engine).
It is Ethanol, not Methanol, that is used in Brazil. Methanol is highly toxic, for one thing, and Brazil's alcohol production comes from sugar cane, which gives you ethanol.
And the cars do not accept both. You have to chose either gasoline or alcohol.
Aside from that, the reason why gasoline is used is really simple: it's the cheapest available, for now.
Slashdot Mirror
AFAIK, there is one non native English speakers among the non-elected. Mind you, there is a healthy number of non-americans among elected and non-elected.
The results, to me, seems reflect how active the candidates have been in the FreeBSD technical mailing lists and commit logs, and how important their contributions have been.
And I'd wager at least one of the non-elected would have been elected had he not spent some months away from FreeBSD in this past year.
So it comes down to lack of non-native english speakers candidates. Since any committer was allowed to become a candidate, and FreeBSD has a good number of committers who are non-native english speakers, I have to wonder why that was so.
There are singles. They are wildly popular in Japan, and I have a good amount of them. Next non-sense, please.
When you compile Java into native binaries, you _still_ append the JVM to these binaries. What do you think makes memory garbage collection in Java? Where do you think these processes will go when you generate the native binaries?
:-)
You are not getting rid of the problem, you are just hiding it. All these "ugly things" prone to errors are simply _hidden_ inside the JVM. But they are _still_ needed, and _still_ used. And written in C.
Heh. Java needs a JVM to run. If you write the JVM in Java, that JVM would need a JVM to run on. Ie, you'd have a JVM written in Java running over a JVM written in C. :-)
:-)
Heh, very practical.
This means nothing. Being scalable means that performance with 30 processors is about the double of performance with 15 processors, and so forth. If this 31 processors machine, running Linux, can deliver more juice than a machine with 8 processors, I'd be surprised.
So you wouldn't let C get anywhere near a secure
system, eh?
Well, Java depends on the JVM. What did you write
the JVM in?
...use the law.
Yes, it would seem the law makes it illegal to offer Internet access to children. So... sue libraries to make it so. That's what's needed to drive the point: escalate it to it's ridicule consequences.
The BSD ports system does that. Well, it actually uses variables that can be overridden to determine stuff such as where things are getting installed, but, by default, everything gets installed in standarized places. See man hierarchy.
The plan is using the same ports tree to ALL BSD.
Frankly, there level of cluelessness of Debian people about ports/package is mighty impressive. There is only _one_ thing that Debian does in an automated fashion which ports/package doesn't which is upgrade.
Yeah, Not Invented Here syndronme is a drag. I mean, why did they have to invent rpm and dpkg instead of using FreeBSD ports/package system?
Well, the OTHER BSDs did not make this mistake, and adopted the ports/package (though ports is called packages on NetBSD, since they already used the word "ports" for something else). But since they are different, the _content_ of the ports tree is different. You can't use the FreeBSD one on OpenBSD. That's what they are unifying.
pkg_add -r xyz? It's smaller. :-)
Well, now, that's an interesting piece of software. Thing is... autoconf works for the platforms the author configured it too. Lately, it is an automated source configuration system that generates the appropriate header files and defines to compile stuff under Linux. :-)
Netcraft says FreeBSD.
Of course, if you had ever read a press release from Walnut Creek, which, as you may recall, has merged with BSDi, you would know it runs FreeBSD.
Well, 3.4 and 3.5 and *not* being worked on. 3.x, 4.x and 5.x are.
.0 syndronme.
.0 release, some avoid the .1 release, and some claim to avoid anything below .5, even.
:-)
FreeBSD uses CVS to manage source code. With CVS, every time you make a change to a file you wish to integrate, a new "version" of that file is created. You can retrieve any particular version of a file, generate diffs between versions, etc.
Now, the versions are numbered in ascending order, as you would expect, but multiple "branches" may exist. For instance, "current" is the HEAD branch, 4.x is RELENG_4, 3.x is RELENG_3,and so on. Each branch progresses independently. One can ask for the latest file of a particular branch. That's what 3.x-stable, 4.x-stable and 5.x-current are.
A release, such as 3.4-RELEASE, 3.5-RELEASE, 4.0-RELEASE or 4.1-RELEASE, is a point in time. We mark the latest version of all files in a particular with a tag, such as RELENG_4_0_0_RELEASE, and those files/version with that tag are the ones that compose a particular release.
Now, why work on more than one branch at the same time? First, let's see how work is done on FreeBSD.
There are different origins to the source code found in FreeBSD. Some of it are externally maintained programs, such as sendmail and bind. These are imported from time to time, when a particular version is deemed stable enough.
Other programs are also developed externally to FreeBSD, but their developers are also FreeBSD committers. These are usually updated on a regular basis. It's the case particularly of some device drivers, shared by FreeBSD and Linux or one of the other BSD. It is also the case of code being developed by companies who sell solutions using FreeBSD, and have internal patches.
Finally, there are the programs "local" to FreeBSD, who are constantly updated. The actual development is still done out of the FreeBSD tree, and only updated at points where the code is functional.
These updates are usually done on the HEAD branch, or current, which, right now, is known as 5.x-current. Because of the very nature of software development, this results in serious bugs from time to time, and even break down of the build process. That's why people should stay away from -current, generally speaking.
As the code matures, and particular versions are deemed safe, they are merged back on the latest stable branch, 4.x-stable. This includes new device drivers and bug fixes. New features are also added in some cases, but the general rule is to leave new stuff out of stable.
Now, when a current reaches a certain point, a new stable branch is created out of it. This branch is identical to current at that point in time, though it quickly starts to diverge. But since it WAS a current up to that time, the new stable isn't *rock* stable previous stable branches. This is the
Because of that, serious users avoid the
These users expect their very reliable stable branch to continue to receive bug fixes and, particularly, security fixes. Thus, we, for a while, merge fixes to the latest two stable branches. Right now, 4.x and 3.x.
It's worth mention, though, that 3.x is at the end of it's life time, and won't be receiving many patches anymore.
Still, some people DO merge fixes all the way to 2.2.x. Usually, they have their own applications still based on such older versions, and like to keep them up to date.
HTH.
AFAIK, both tcsh(1) and less(1) were imported under the BSD license.
Anyway, FreeBSD's more(1) was a very old version of less(1).
They also have a whole different perspective. See, for instance, Kareshi Kanojo no Jijyo, which was aimed at high/junior high girls, and aired at 6pm (5:30pm through 7:30pm is the typical time for most cartoons). Their main characters had, , sex! :-) Not that there was an actual sex scene, but there wasn't any doubt about the event either.
In Japan, they make anime for all ages. They have kids stuff, teen stuff, and adult stuff (both sexual content and non-sexual content).
If this is the series I saw last year, it is most definitely NOT similar to BubbleGum Crisis in any way. Though they share the same universe, AD Police has a very dark feeling to it. Likewise, the art is completely different.
A program tells you how to reach a goal. Anything else is not a program. This is the definition by which I stand (Prolog or no Prolog :).
That you disagree with that pretty much sums up our differences.
Actually, I meant all OSS OS . Since gcc is the only OSS compiler out there with IA64 support, and the OSS OS I know of all depend on some special gcc features anyway, ... <shrug>
I'm pretty sure most of the corporations out there writing closed source software for Linux are using gcc, because that's the only Real compiler available for Linux. That is, until Borland decides to show up.
Being Palmeiras, myself, I must say your conclusion is right. :-)
One problem with GCC back-end is that the intermediate language sucks horribly. It's completely inadequate for expressing parallelism, ordering and dependence issues.
:-(
For this reason, all OSS will suck very, very badly on IA64, btw.
Err, the what the program must do can be defined in declarative language, where you specify assertions and invariants that must be true in every execution of the program (actually, temporal logics statements).
An automatic formal correctness validation program will then verify these against some code that describes _how_ to achieve those results.
For instance, check Spin/Promela, and the very simple Mutual Exclusion examples. Declaring what a Mutual Exclusion algorithm must do is simple, and very different from actually writing a program to do it.
Could you please try again in English? I'm having a hard time parsing what you said.
The energy density for either ethanol or gasoline is incorrect. Brazilian ethanol-based cars had efficiency only 30-50% inferior to gasoline (range -- power was always much more a function of the engine).
Brazil uses ethanol, not methanol.
:-)
But, then, this stuff evaporates. Gasoline evaporates too. You simply don't let it on the open.
It is Ethanol, not Methanol, that is used in Brazil. Methanol is highly toxic, for one thing, and Brazil's alcohol production comes from sugar cane, which gives you ethanol.
And the cars do not accept both. You have to chose either gasoline or alcohol.
Aside from that, the reason why gasoline is used is really simple: it's the cheapest available, for now.