> I just want to remind the FreeBSD devs (you probably know, but I'm saying
> it anyway): a bunch of users who aren't contributing to this flame war do
> in fact appreciate how you think about options and consider what's best for
> FreeBSD. You have taken the effort to consider an idea that is currently
>> This is a "modern" programming where morons dominated. Common.
> Wojciech, we got it. FreeBSD is perfect for you. You do not care about
> what other people need, think and want. It's okay for you when FreeBSD's
> user base shrinks until you are its last user.
Definitely not last.
> Can we other people now discuss how we can FreeBSD make relevant again?
revelant for what?
> Fair enough, as a user of FreeBSD, may I suggest a way to make FreeBSD
> "relevant again" is to start eliminating bugs that are show-stoppers
> for users and cause those users to switch to alternatives, instead of
> obsessing with toys-du-jour?
On Monday, January 07, 2019 14:03:05 +0100 Wojciech Puchar <[hidden email]> wrote:
>> I just want to remind the FreeBSD devs (you probably know, but I'm saying
>> it anyway): a bunch of users who aren't contributing to this flame war do
>> in fact appreciate how you think about options and consider what's best for
>> FreeBSD. You have taken the effort to consider an idea that is currently
> If not from one side then from another side you want to enforce stupid ideas to
> FreeBSD. Simply stop this discussion about rust, java or whatever and start
> separate project if you like
If you are so against change why don't you fork FreeBSD? That way YOU can
decide exactly what goes into WP-BSD and what does not!
There has been some great information exchanged in this thread and I have
enjoyed the thought provoking discussion. I have been using the C language
for 40 years. Perhaps it is time I looked at something more modern, not to
replace it, to complement it.
On 1/7/19 4:06 PM, Wojciech Puchar wrote:
>> Fair enough, as a user of FreeBSD, may I suggest a way to make FreeBSD
>> "relevant again" is to start eliminating bugs that are show-stoppers
>> for users and cause those users to switch to alternatives, instead of
>> obsessing with toys-du-jour?
> and even more important - stop introducing new bugs by adding this toys.
Hello. I am testing FreeBSD instances with long term view exactly
because of "toys" in linux.
My idea is to have and keep OS for $purpose which is not bloated with
C is fine and if it works on tests, I am going out from linux. Shiny
things are shiny, but try to maintain those for 5 years when everyone
adding a $feature every week. I am tired of those many shebangs like Go,
Rust, whatever on production. It is probably nice to play, but you need
stable things when getting older. Those my 50 cents and only point of view.
On Fri, Jan 4, 2019 at 4:50 PM Brian Neal <[hidden email]> wrote:
> Just go to http://godbolt.org/ and type a small program in each language, enter the appropriate compilation flags and compare the output. The function I used took a count as a parameter, iterated through the count, summed up odd numbers and returned the sum.
I did the test with what I understood must had been the code you used,
but my results are different. See .
> >> It was a debug build with no optimization for either compiler. But we
> >> can easily run a variety of settings for comparison:
Debug builds show also panic and overflow checks for Rust sources,
which explains the difference in instruction count.
> >> Compiler Flags Inst. Count Build Time
> >> ======================================================================
> >> clang 7.0.0 none 33 296ms
> >> -O3 23 341ms
> >> rustc 1.31.0 none 110 606ms
> >> -C opt-level=3 67 643ms
> >> gcc 8.2 none 37 211ms
> >> -O2 24 249ms
> >> -O3 119* 206ms
> >> * With -O3, gcc unrolled and vectorized the loop. The other compilers
> >> did not emit vectorized code at any of the standard optimization levels.
I did not see this. Actually I had to force Rust with extra flags to
stop it from emitting such code.
In fact, both Rust and clang generate the exact same code for the
> >> So, essentially, double the build time and ~3 times the code for the
> >> same logic.
This is not true in the tests I did wrt instruction count. The
compiler is certainly slower, although not sure it is 2x slower than
In fact, as you can see, there's one implementation in Rust that beats
the C code in inst count for both gcc and clang.
That said, instruction count is hardly a good metric, especially with
relatively recent CPUs.
My 2c: these tests focus on a very narrow set of properties and cases
that IMO should not be the basis for considering a language.
> If you are so against change why don't you fork FreeBSD? That way YOU can
> decide exactly what goes into WP-BSD and what does not!
already do it to some extent
> There has been some great information exchanged in this thread and I have
> enjoyed the thought provoking discussion. I have been using the C language
> for 40 years. Perhaps it is time I looked at something more modern, not to
> replace it, to complement it.
>> and even more important - stop introducing new bugs by adding this toys.
> Hello. I am testing FreeBSD instances with long term view exactly
> because of "toys" in linux.
for those who think FreeBSD should be more like linux (or whatever).
Take linux for example. 15-20 years ago or so there was great pressure on
linux to be windows competition.
X11 which was already quite bloated to start with (but anyway working and
quite logic) was the base on which "desktop environment" started to be
created. Then X11/Xorg itself got "improved" which resulted in nonsense.
Now for example X over network is almost unusable because instead of X
server doing things - lots of libraries took it's job putting whole
bitmaps as a result.
What is final result - those who want windows like product choose...
windows. Which is logical.
Linux penetration on "desktop" market is zero+small measurement error.
Linux is only popular in server environment. Why not FreeBSD? Because
linux got more marketing.
If FreeBSD will go being "more like linux" then people will get away from
it. Those who want to have system "more like linux" already uses linux.
Those who not will stop using FreeBSD.
Same was some years ago with NetBSD. And what will remain? DragonflyBSD?
For how long. We will see.
Sad smart people here cannot understand basic logic, and get overhelmed
with common marketing.
> Going back to my previous statement, I think writing a service monitor (to work alongside init and rc) in modern C++/rust would be a good item to undertake.
> I’d be willing to do this with someone else, as a research project/to demo how rust could be used.
> Given prior comments about rust binary sizes and the fact that the default linking option is mostly static, a “mission critical binary” like this (or rescue?) would be a good candidate for rust.
Circling back a bit late (I'm swamped right now) to make one final
I think it would be a useful exercise to try and get a minimal
rust-based UEFI boot loader up and going. When I have some more free
time (hopefully soon), I might take a swing at it.
> Circling back a bit late (I'm swamped right now) to make one final
> I think it would be a useful exercise to try and get a minimal
> rust-based UEFI boot loader up and going. When I have some more free
> time (hopefully soon), I might take a swing at it.
So if (and we all know where this is headed!) that were to make it
into the distribution, how many compilers would one need to compile to
actually compile a FreeBSD distro by then?..