PR the PR. Is it worth it?

So you mean FreeBSD isn't a collaborative effort anymore?
It doesn't seem so.
In the last century the people in charge were visible. One might actually have sent them an e-mail (and might even have got an answer), but I never dared, because they were so great in skill, they were just gods.
Now look how it is today, just two recent events:
Item: The mailinglists suddenly show strange failures, and slowly it figures that the software has entirely been replaced, in the course of a clandestine change. Nobody knows anything about it except hearsay or interpretation of the error messages.
Item: Somebody here asks if the spectre stuff is implemented at all, and inhowfar. Nicely done! Finally, somebody dares to ask! And then - mobody has solid data, it is peacemeal all over, if existent at all.
I for my part have a setting that I have collected from looking into the sources, which is " hw.ibrs_disable=0 hw.spec_store_bypass_disable=2 hw.mds_disable=3" - and that may or may not be correct and may or may not be sufficient, I don't know (but it slows bhyve by more than half). And then I don't know if I still need these when compiling with RETPOLINE, or if I should compile Kernel or world or both with retpoline, or whatever. And I think with an issue that was media coverage all over at the time, this is quite poor.

Some insiders somewhere would have the information, but we, the users, the inferiors, are out of the loop and can resort to spending hours reading the code and trying to understand what it actually does.
I won't call this collaboration.

Not to mention the overwhelming buerocracy that has been built up in between. As mentioned, in the old times the gods were visible, and if you actually would have an improvement, you would just have talked to them (or they would have talked in the railway about their personal backdoors, which every developer had, and which was just fine).
Today nobody is visible, and it's a vast machinery. If you want to fix something, you have to provide tests for it (strangely, the original bug didn't need to be tested), you need to provide sponsors that would approve the fix, and so on.
And all over this all is the great Google code of conduct, which says that you must never say anything negative: Brokenness must not be criticised, flaws not be mentioned, and defects accepted - in fact, brokenness, flaws and defects are probably forbidden words because somebody could have their feelings hurt from them.

If you don't want big corporations to be able to make money using your code, don't share it on the web, or choose a license which bans commercial use. I don't know if such a license exists, but if not you can write your own. When you relase something as BSD, GPL, MIT, etc. you know that anyone will be able to use it, including big business.

No problem with that. It is intended that they steal it. Then, when their crap malfunctions, I can simply look into the Berkeley sources to see what is going wrong. (Done this, it works.)
 
there is a gentry, and there is the plebs.
Y'know, there's a reason for "That guy is the expert, and you're not". For example, I never understood Fast Fourier Transform - and somebody like Bill Joy would.
And if you manage to get an audience with a developer - I have already two or three times seen them openly admit that the only way to get something done is via insider relationships.
Any dev worth their salt would have a pretty full schedule that would take some effort to rearrange. Who would they make that effort for?
Today nobody is visible, and it's a vast machinery
The complexity of that machinery just swallows information, instead of allowing it to pass to the destination. ? Expertise, coupled with insider relationships, is pretty much a prerequisite to overcoming that.
 
Meanwhile, the original PR 258271 received some discussion, including something I'd call a shouted zealot argument… for a bit of background, unfortunately, base received a commit adding a function (therefore extending the userspace API) without immediately bumping OSVERSION. For chromium, it's relevant whether this function exists or not. The cleanest way to check base is checking for OSVERSION, and in this case, it would give a wrong result for 14-CURRENT built in the time between the commit adding the function and the following OSVERSION bump; roughly two days. If that's not acceptable, all you can do is an explicit check, but the way it is done right now is bad: it's executed every time and it makes make spit a warning when it fails.

So now, I really want to see that fixed, having suggested both IMHO possible solutions…
 
... I simply won't do it again. As my spiritual teacher used to say: you cannot hinder one from learning. ...

There is, if you like, the opportunity to learn (from the shared experiences of others here) that:

... not worth to submit PR; that is a WORN device (Write Once Read Never). ...

-- this is not the case.

... ready-made patches for very obvious base-OS coding mistakes) from the old tool will finally be read by somebody (waiting 12 or 13 years ...
 
... I simply won't do it again. As my spiritual teacher used to say: you cannot hinder one from learning. ...

There is, if you like, the opportunity to learn (from the shared experiences of others here) that:

... not worth to submit PR; that is a WORN device (Write Once Read Never). ...

-- this is not the case.

... ready-made patches for very obvious base-OS coding mistakes) from the old tool will finally be read by somebody (waiting 12 or 13 years ...

Can you share URLs? Thanks
 
Y'know, there's a reason for "That guy is the expert, and you're not". For example, I never understood Fast Fourier Transform - and somebody like Bill Joy would.

Yes, thats why you shouldn't file PRs, you should not read the code, you should not understand computers, you should not fix the bugs - because you're just too stupid for that!

And that's what has changed. In the last century we wanted people to understand the Internet, and computers. In 1993 I explained the possibilities of IoT in adult learning centers. Today I get told that I am too stupid to understand computers.

The complexity of that machinery just swallows information, instead of allowing it to pass to the destination. ? Expertise, coupled with insider relationships, is pretty much a prerequisite to overcoming that.
Then why is the skill of the elite such low, that it took a friend of mine with no computer knowledge only half a year to become a member of the renowned developers elite?
(Then when I asked her what kind of expertise -sic!- she would consider important for her new role as software architect, and named a few from the background of my experience, her answer was: 'that is out of question, nobody has such experience!')
 
Can you share URLs? Thanks
I did.
Sorry, I just recognized that You seem to have not gotten to the topic of the thread. It is about the PR database. So obviousely there is no URLs, as that is a database: there are record numbers, and everybody can search for the entries made by me.
 
I did.
Sorry, I just recognized that You seem to have not gotten to the topic of the thread. It is about the PR database. So obviousely there is no URLs, as that is a database: there are record numbers, and everybody can search for the entries made by me.
When Geezer linked to the PR, that was a link, a URL. How to get to the database and dig up the info is a matter of expertise. Sure, you cut through the crap and realize that people on the other side are just as stupid as you are. Difference between you and such people is some awareness of the system. Those who do rise above all that - they're the ones who don't have to deal with that crap, they have insider relationships, and no real need for the expertise. Owners of the Evergreen ship don't have any expertise in naval navigation, but they do own the ship, and can hide behind money and bureaucracy.
 
Back
Top