Since you mentioned it, here's an update. My testing went well except for one issue which was with unlocking after the screen locked. That turned out to be because I'd built using a jail that was built before pam was updated, but was testing on a system after the pam update (11.0-BETA2).
Also, the sddm package didn't build because the kdemerge tool can't merge the UIDs/GIDs files. That was changed to go ahead and build the package and give a pkg-message to create the user.
I want people to be able to test using 11.0-BETA2 and have sddm, so I've updated the jail and am currently in the process of rebuilding the packages.
Because the jail changed, everything builds from scratch, so it's taking a little while, but when they're done building (should be soon), I'll test some more and write up some docs on testing KDE5 and post them for those who are interested.
Oh, and to give credit where it's due, all I'm doing is setting up poudriere and jenkins. The guys working in the area51 deserve all the real credit for doing the real hard work of getting things working.
There's also some work around the OS installer to implement a new menu where OS security features are turnable, it wasnt on the report, but I hope it gets to the 11.0-RELEASE.
Really cool to see active work on patching Ceph to run on FreeBSD. There should be some advantages by running Ceph OSD on ZFS, but there is very little information about if ZFS work well with Ceph even on Linux. Transparent compression and checksum validation on read are two features I would love have on a Ceph cluster.
on a somewhat related note: if you're reading this and you use OpenSSH, you really ought to donate to the OpenBSD project via their foundation. And you should band together with the rest of your technical team(s) who most likely also use OpenSSH, and get management to make a donation in kind.
+1 EVERYONE uses OSSH. The OBSD foundation should be just rolling in cash like scrooge mcduck from everyone donating. I think it's pretty sad and says a lot about the IT industry that they are not. Considering that everyone uses it and it's a pretty damn vital part of everyones core infrastructure.
Edit: I debated how to phrase some of this and apparently was not careful enough based on the reply. I in no way meant to imply that OpenBSD was for profit, scummy, taking money or any such thing or hadn't carefully formulated their bylaws or weren't following them. I have tons of respect for them and have repeatedly donated myself. What I was arguing (and am far from the first) is that they have made it harder and less rewarding in numerous small ways that affect donations, and I stand by that.
----
True, but at the same time (and this is not an uncommon pattern with the OpenBSD team) they have thrown up some silly roadblocks that shouldn't deter individual small contributions, but are certainly of concern for large contributions or GP pyvpx's suggestion of organized donations and matching ones, ie
>"and get management to make a donation in kind"
Unlike FreeBSD and pretty much every other serious donation-supported project (including NetBSD) the OpenBSD Foundation is not a [strike]legal non-profit[/strike] "tax deductible charity" (in the US that'd commonly be a 501(c) tax empty). So donations are not tax deductible and may run into barriers that others sail through. Many of the matching programs I've seen for example simply have official non-profit status as a flat-out requirement. While of course it might be possible to negotiate exceptions with management, just in having the conversation at all we're already talking massively more friction, and friction is the enemy of spending.
OpenBSD has some little bit of handwaving about it (Canadian, too much trouble) which may well be valid in isolation but is irrelevant in the larger picture, and feels more like a common pattern of prideful disdain at being about "anything but the code". But to the extent money from non-coders is considered important, the interests of non-coders also have to be at least mildly considered if an increased response rate is desired. It's the 100% right of OpenBSD to make it a PITA and have snark and proudly run rough sites and such, but of course that's going to have natural consequences in interactions with the rest of the world.
There's no right or wrong answer here, but I don't think your "it's pretty sad and says a lot about the IT industry that they are not" actually fully captures the situation. Other foundations are registered non-profits, have somewhat nicer pages (not crazy webapp monstrosities, but even little things like simple acknowledgment of smaller donors that OpenBSD blows off), and so on. Donors are special and rare, and a bit of personal recognition and appreciation is free and can go a long way. A lot of coders may dislike the softer general human networking side of things, but tossing it aside will generally result in a reduced experience unless there is some other form of stickiness.
This is so blatantly wrong, I had to create an account.
Yes, it is true The OpenBSD Foundation is not a US 501(c)3 (side note: that is not the only type of US non-profit). That is because instead it is a _Canadian Not-For-Profit-Corporation_, which is a legal non-profit for Canada.
Please, do NOT spread FUD that The OpenBSD Foundation is not a non-profit. It absolutely is.
I should also point out, that crossing the border to Canada for donations has not been a problem for Duck Duck Go, Core Infrastructure Initiative, Microsoft, Facebook, Google, Yandex, genua, HP, etc.
Yes, it is true The OpenBSD Foundation is not a US 501(c)3 (side note: that is not the only type of US non-profit). That is because instead it is a _Canadian Not-For-Profit-Corporation_, which is a legal non-profit for Canada.
This is absolutely true; however, the OpenBSD Foundation is not a charitable organization (and donations don't get any special income tax treatment) -- because Canada is far more restrictive in our definition of "charity". The FreeBSD Foundation wouldn't have any special tax status if it was set up in Canada either.
>Please, do NOT spread FUD that The OpenBSD Foundation is not a non-profit. It absolutely is.
I have added an edit and tried to reword that bit slightly, I hope that you find it a little better. It was an honest terminology flub I guess, when I used "legal non-profit" I was aiming for the more colloquial sense it's often used in America when discussing "donations", which is the subtopic at hand here, wherein it tends to be taken for granted that the entity provides receipts for tax deduction. However, I can see how it'd be confusing and could be taken the wrong way, or feel like a slur. FUD was the very farthest thing from my mind.
I stand by the thrust of the post however. The quality of code produced and its foundational status for much of the development world is not in question, but I don't think the (often celebrated) "roughness" of Theo et al in small ways is either (again, mostly in small ways like not listing anything but huge donors or that Comic Sans initial LibreSSL site [1]). This is not a value judgement; I think there are good arguments for both sides about the pros and cons of "public friendliness" and the resources that takes up vs the return for any given project. But it's not fair to pretend that abrasiveness is or should be cost free either. When you launch a project like LibreSSL in the midst of a relatively huge (and as always temporary) amount of temporary news coverage over the subject and the first general impression of the project to the general public is [1]
>"This page scientifically designed to annoy web hipsters," the site says. "Donate now to stop the Comic Sans and Blink Tags."
well, that may or may not result in a lot of people "donating now" right? Like it or not webs of trust, proxies, and authorities are the methods people have to use to evaluate most of the information input they deal with in life, at least as a first pass filter.
I want OpenBSD to make as much money as they need, but I don't think they're immune to basic forces of competition that everyone else faces either. I'm honestly not sure if they're actually even facing any money issues they care about beyond a basic "more is certainly helpful and would allow for more hardware testing and the like". There are other models beyond soliciting individual small donations, and I see significant corp ones (and pressuring other large companies to toss in $10-50k a year might be effective, why isn't Apple in Gold/Platinum?). But in the restricted context of the post I was replying too arguing that the lack of tons more coming in from smaller distributed sources, small businesses and so on, and then slamming all involved, well I don't think that's entirely fair. OpenBSD could do better there, if they need/want to. And I've repeated that because if they're happy with how things are now then there is certainly no need for them to change. Not everything is about getting as much as possible, if they're satisfied with what they have as "enough" then good for them.
I also find it very interesting that the funding of open source projects quote 'needs' un-quote to be via the charity + tax rebate model. Why does OpenBSD (or FreeBSD, or even political billionaires for that matter) need to compete with education for children, law enforcement, roads, social services, etc? Funding open source projects shouldn't cause other programs to suffer. This is software we use and depend on every day.
Additionally, I am in Europe. Donations to US 501(c)3 orgs are not tax deductible for me. The charitable status of the Foundation I wish to fund is not a consideration to me.
Quote from the OpenBSD Foundation website: "If a penny was donated for every pf or OpenSSH installed with a mainstream operating system or phone in the last year we would be at our goal."
Also remember that a $5 donation to a non-profit in the USA is pretty valuable since there are requirements relating to number of donors. Big donations need a lot of little donations to make up the numbers.
I've also had the FreeBSD Foundation as my Amazon Smile beneficiary ever since Smile was introduced. It's not a huge amount (0.5%), but I shop a lot on Amazon.
The organization of these status reports is outstanding and so structured, like the rest of FreeBSD's documentation and communication.
I wish more of the HardenedBSD features would land in FreeBSD trunk. Other than that, I'm really glad to see that it's making great progress, like RISC-V support. The address randomization feature in 11 is ASR (not ASLR), per the review comments by the inventor of ASLR (PaX dev), so it's a pity the initial HardenedBSD devs decided to not continue upstreaming things after they felt the ASLR patch review was taking too long. OPNsense seems to be basing itself on HardenedBSD, so that's nice to see.
This is not exactly what happened. People behind HardenedBSD code take criticism of their code personally and are very, very, very reluctant to adhere to advices on correction of the code, or design or even processes around their code(one of the main points aganist accepting their ASLR code was that it wasn't designed, but ...just written) so the claims of that code being well tested, well written and in general production ready quality should be taken with a grain of salt.
However, its worth noting, that if it wasnt for them persistently making a lot of 'noise' around this particular feature, FreeBSD guys wouldnt come up with their own implementation anytime soon.
I see, that's unfortunate. TBH, I wasn't entirely sure what to make of the comments in the ASLR Phabricator ticket, and it looked like they gave up after failing to address the VM comments.
Do you know if there are there plans to implement the rest of the important mitigation techniques?
To be honest, I am not sure there are such plans. First of all, there's that discussion (and lack of agreement) between FBSD implementation author and the ASLR idea author on what's the 'L' there really is (or what it should be), and second, there is another division of opinions wether the ASLR is worth much in first place, given there were successful bruteforce (and other) cracking reports for other platforms proud ASLR implementations.
> wether the ASLR is worth much in first place, given there were successful bruteforce (and other) cracking reports for other platforms proud ASLR implementations.
That is because ASLR, by itself, is almost totally worthless, and is meant as a stop-gap to stop certain direct code attacks (vs "data only" attacks). It is a stop-gap because most modern systems are completely riddled with things like infoleaks, and you only need to leak one pointer to actually defeat the setup completely.
The real vector that's sitting around to be killed is control-flow based exploits (e.g. ROP, simple stack smashing, vtable ptr overwrites, all those de jour exploit techniques). You need a powerful form of control-flow integrity to stop this at the software level. You also need a method to actually help mitigate information leaks so they can do less damage, and increase attacker cost (e.g. "execute only pages" are worthless if all users have the same kernel image. I can just download your GENERIC kernel elf image, and just find the opcodes to do e.g. a ROP attack anyway. grsecurity uses compiler plugins that randomize kernel stacks and the compilation method with a particular private seed, at compile-time, so every compiled grsecurity kernel is different from the last one).
TBQH: FreeBSD is probably better off copying the other twenty gazillion exploit mitigation features from grsecurity that can reasonably stop exploits, even by themselves, dead in their tracks - like UDEREF, KERNEXEC, refcount overflows, triggering the kernel on unmarked signed overflow, the compiler plugin features, etc. Those will actually ban classes of exploits outright, every time, and always work, without wasting time through lots of wincing over the finer details, like ASLR.
You won't get to parade "look at our weak ASLR implementation!" (thankfully), but I feel we already have enough of that going around.
An implementation of FreeBSD sensor framework[0] suffered a similar fate/criticism -- it was incorporated as a GSoC project (ported from OpenBSD iirc), and presented at BSDCan but happened to be ripped out just before (again, iirc) the presentation[1]... and phk[2] said (roughly) that "'good enough' is the enemy of 'good'", which as a phrase is simple, catchy, and worth remembering (I obviously did). The discourse around things like engineering decisions in the *BSD camps is mostly civilized, and a treat to witness...
[1] I attended the BSDCan this was presented at, and sat close to phk and witnessed the exchanges about the technical merits, problems, "'good enough' vs 'good'", but am recalling from memory.
Of particular note: the core team takes action against bad behavour. I wish others would.
I'm not talking about Linus. Linus swears, I think that's almost OK. No, I'm talking about the people who go out of their way to be unpleasant. Some of them swear too, but saying fuck isn't the heart of what makes them bad. And I wish Linus wouldn't swear — he attracts too much criticism and shields people who could use a little headwind.
If any freebsd people read this, could you please have a quick look at ff-wbe1.nyi.freebsd.org, which is thanking me for my generous donation once per minute?
On behalf of the FreeBSD Foundation, I want to apologize for this inconvenience. We are experiencing a problem with our receipt generator right now. We have someone looking into the issue right now. Thank you for your support and donating to the Foundation!
Looks like the nosh homepage is gone? Do you happen to know if the project has moved, or is available anywhere? I find various outdated links, but nothing up to date on nosh anywhere.
It has moved. There's an article on the new WWW site about what happened.
There's a new version of nosh ready on the new WWW site. I'll be announcing in the usual places soon. I believe that it has a few things of interest to people, including (given what was said above) a slight further extension on the cross-platform front.
No. It's not germane to the softwares themselves. It's only germane rather to the people who've been variously asking me what happened to the old WWW site, whom I have been thanking for their patience until the new WWW site was up.
As I said, it's on the new WWW site, and you can read it there.
For want of a better place, I put it on the new WWW site in the "author" section. For now. The change of WWW site motivated me to do some restructuring of things that I laid out decades ago and tidy up stuff that was only there for some old URLs that were floating around (that don't point to the new WWW site of course, making the fixes for them irrelevant). I still haven't settled on the layout of the "author" section, and it might change. Any URL valid now might not be valid in months and years to come when this comment is still visible to the world. And I have just been tidying up the long-term consequences of stale URLs on discussion fora from years ago.
So just follow an author hyperlink, from pretty much any page, to the (current) author section and proceed from there.
Previously service administration was different from linux distro to linux distro. This is of course no problem for FreeBSD, since there wasn't such a difference to begin with. One feature that FreeBSD may be missing is the dynamic behavior of desktop and mobile machines, which doesn't seem to map well to the existing init scripts.
While systemd clearly helped consolidate and make administration more predictable across linux distros, there are deficiencies and regressions due to systemd which for the most part didn't exist in the pre-systemd era. It may be due to the scope of functionality systemd aims to cover, but some of the unconventional or missing command line options don't help either. However, it's used by enough mainstream distros that I expect the kinks to be fixed with time.
I'm familiar with systemd. I've used it lots. Admittedly I'm not a fan of systemd but that's personal preference.
I was more interested in why the OP didn't consider FreeBSD to have a "useful init system". Just wondered if it was a preference thing or if there were features s/he considered it to be missing or were perhaps unaware of.
> One feature that FreeBSD may be missing is the dynamic behavior of desktop and mobile machines, which doesn't seem to map well to the existing init scripts.
I keep seeing this argument, and i keep wondering what it is actually trying to say.
Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working.
But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.
Then again, maybe i am not the laptop packing dev convention goer that seems to use their laptop more like an oversized phone than a laptop (never mind a desktop).
Edit: damn keyboard ignored the copy command somehow, so i had the wrong quote pasted...
You're right. I've trusted the content of Jordan Hubbard's presentation, seeing how he was inside OS X for a long time and is a FreeBSD expert too, and didn't question the validity.
> Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working. But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.
Funny enough, FreeBSD is handling runtime hardware changes neither in its init process or rc scripts. Instead the FreeBSD kernel has a single-reader device event channel, which is read by devd. The submitted events range from ACPI laptop lid close/open, to added usb things or ZFS errors. They are matched against configurable rulesets and their respective actions executed. Loading kernel modules, starting daemons etc.
Devd also multiplexes the received events to arbitrary numbers of additional consumers via a number of available sockets in /var/run.
If you care that much about init just use nosh, s6,runit or daemontools... you don't have unit-files but a similiar short shellscript and some small helper tools, stdout, stderr and respawn behavoir are also very similiar (well systemd was inspired by this). runit also provides good logging capabilities. Socket activation is also possible with these tools and has been for almost 15 years.
Could you eloborate where you had problems? The BSD init system is already quite clean, much cleaner than sysvinit.
I'm not sure what systemd features you need but most if not all can be replaced by small unix tools - that's kind of the point of the BSD philosophy.
How is BSD init not useful? All it's supposed to do it start and maybe stop services, and it does that quite well.
BSD init is pretty small and clean. I would argue systemd is much less so because of the large scope of the project. The more lines of code and features you have means there's going to be more bugs and more ugliness, and that's true for all large programs. New doesn't mean better either. If it isn't broken and still works well, then you don't need a replacement, which really is why systemd exists to begin with. Sysvinit was a god awful and byzantine program IMO.
I am excited to read about AllWinner support. How do I find out which devices are impacted? I have a Cubietruck (aka Cubieboard 3) and it would be great if I could run FreeBSD on it...
Cubietruck definitely works! There is no pre-configured image, so you need to build your own. Easiest is to start with another Allwinner image (say the Cubieboard2 one), replace U-Boot with the one for your board, and add your dtb.
Look at ports/sysutils/u-boot-cubieboard2 for a template on how to build a suitable U-Boot, and sys/boot/fdt/dts/arm/cubieboard2.dts for a template for your dtb.
It's really unfortunate that the wiki is so neglected. I've gotten to the point where I can't simply trust anything on it anymore. It has (had?) the potential to be such a great resource to compliment the Handbook.
71 comments
[ 2.4 ms ] story [ 125 ms ] threadSyStEmD depends on dbus. You can depend on dbus without depending on SyStEmD but you can't depend on SyStEmD without depending on dbus.
Oh, and yea, systemd depends on dbus, not the other way around. (one of the dumbest decisions in the whole thing, if you ask me)
https://twitter.com/swills/status/757797521133449216
Also, the sddm package didn't build because the kdemerge tool can't merge the UIDs/GIDs files. That was changed to go ahead and build the package and give a pkg-message to create the user.
I want people to be able to test using 11.0-BETA2 and have sddm, so I've updated the jail and am currently in the process of rebuilding the packages.
Because the jail changed, everything builds from scratch, so it's taking a little while, but when they're done building (should be soon), I'll test some more and write up some docs on testing KDE5 and post them for those who are interested.
0. https://www.freebsdfoundation.org/donate/
http://www.openbsdfoundation.org/
>"and get management to make a donation in kind"
Unlike FreeBSD and pretty much every other serious donation-supported project (including NetBSD) the OpenBSD Foundation is not a [strike]legal non-profit[/strike] "tax deductible charity" (in the US that'd commonly be a 501(c) tax empty). So donations are not tax deductible and may run into barriers that others sail through. Many of the matching programs I've seen for example simply have official non-profit status as a flat-out requirement. While of course it might be possible to negotiate exceptions with management, just in having the conversation at all we're already talking massively more friction, and friction is the enemy of spending.
OpenBSD has some little bit of handwaving about it (Canadian, too much trouble) which may well be valid in isolation but is irrelevant in the larger picture, and feels more like a common pattern of prideful disdain at being about "anything but the code". But to the extent money from non-coders is considered important, the interests of non-coders also have to be at least mildly considered if an increased response rate is desired. It's the 100% right of OpenBSD to make it a PITA and have snark and proudly run rough sites and such, but of course that's going to have natural consequences in interactions with the rest of the world.
There's no right or wrong answer here, but I don't think your "it's pretty sad and says a lot about the IT industry that they are not" actually fully captures the situation. Other foundations are registered non-profits, have somewhat nicer pages (not crazy webapp monstrosities, but even little things like simple acknowledgment of smaller donors that OpenBSD blows off), and so on. Donors are special and rare, and a bit of personal recognition and appreciation is free and can go a long way. A lot of coders may dislike the softer general human networking side of things, but tossing it aside will generally result in a reduced experience unless there is some other form of stickiness.
Yes, it is true The OpenBSD Foundation is not a US 501(c)3 (side note: that is not the only type of US non-profit). That is because instead it is a _Canadian Not-For-Profit-Corporation_, which is a legal non-profit for Canada.
Please, do NOT spread FUD that The OpenBSD Foundation is not a non-profit. It absolutely is.
Proof: Canada Federal Corporation Information https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDt... The OpenBSD Foundation Bylaws: http://www.openbsdfoundation.org/foundation/bylaws.html
http://www.openbsdfoundation.org/contributors.html
This is absolutely true; however, the OpenBSD Foundation is not a charitable organization (and donations don't get any special income tax treatment) -- because Canada is far more restrictive in our definition of "charity". The FreeBSD Foundation wouldn't have any special tax status if it was set up in Canada either.
I have added an edit and tried to reword that bit slightly, I hope that you find it a little better. It was an honest terminology flub I guess, when I used "legal non-profit" I was aiming for the more colloquial sense it's often used in America when discussing "donations", which is the subtopic at hand here, wherein it tends to be taken for granted that the entity provides receipts for tax deduction. However, I can see how it'd be confusing and could be taken the wrong way, or feel like a slur. FUD was the very farthest thing from my mind.
I stand by the thrust of the post however. The quality of code produced and its foundational status for much of the development world is not in question, but I don't think the (often celebrated) "roughness" of Theo et al in small ways is either (again, mostly in small ways like not listing anything but huge donors or that Comic Sans initial LibreSSL site [1]). This is not a value judgement; I think there are good arguments for both sides about the pros and cons of "public friendliness" and the resources that takes up vs the return for any given project. But it's not fair to pretend that abrasiveness is or should be cost free either. When you launch a project like LibreSSL in the midst of a relatively huge (and as always temporary) amount of temporary news coverage over the subject and the first general impression of the project to the general public is [1]
>"This page scientifically designed to annoy web hipsters," the site says. "Donate now to stop the Comic Sans and Blink Tags."
well, that may or may not result in a lot of people "donating now" right? Like it or not webs of trust, proxies, and authorities are the methods people have to use to evaluate most of the information input they deal with in life, at least as a first pass filter.
I want OpenBSD to make as much money as they need, but I don't think they're immune to basic forces of competition that everyone else faces either. I'm honestly not sure if they're actually even facing any money issues they care about beyond a basic "more is certainly helpful and would allow for more hardware testing and the like". There are other models beyond soliciting individual small donations, and I see significant corp ones (and pressuring other large companies to toss in $10-50k a year might be effective, why isn't Apple in Gold/Platinum?). But in the restricted context of the post I was replying too arguing that the lack of tons more coming in from smaller distributed sources, small businesses and so on, and then slamming all involved, well I don't think that's entirely fair. OpenBSD could do better there, if they need/want to. And I've repeated that because if they're happy with how things are now then there is certainly no need for them to change. Not everything is about getting as much as possible, if they're satisfied with what they have as "enough" then good for them.
[1]: https://arstechnica.com/information-technology/2014/04/opens...
Additionally, I am in Europe. Donations to US 501(c)3 orgs are not tax deductible for me. The charitable status of the Foundation I wish to fund is not a consideration to me.
Quote from the OpenBSD Foundation website: "If a penny was donated for every pf or OpenSSH installed with a mainstream operating system or phone in the last year we would be at our goal."
I've also had the FreeBSD Foundation as my Amazon Smile beneficiary ever since Smile was introduced. It's not a huge amount (0.5%), but I shop a lot on Amazon.
Money well spent.
I wish more of the HardenedBSD features would land in FreeBSD trunk. Other than that, I'm really glad to see that it's making great progress, like RISC-V support. The address randomization feature in 11 is ASR (not ASLR), per the review comments by the inventor of ASLR (PaX dev), so it's a pity the initial HardenedBSD devs decided to not continue upstreaming things after they felt the ASLR patch review was taking too long. OPNsense seems to be basing itself on HardenedBSD, so that's nice to see.
However, its worth noting, that if it wasnt for them persistently making a lot of 'noise' around this particular feature, FreeBSD guys wouldnt come up with their own implementation anytime soon.
Do you know if there are there plans to implement the rest of the important mitigation techniques?
That is because ASLR, by itself, is almost totally worthless, and is meant as a stop-gap to stop certain direct code attacks (vs "data only" attacks). It is a stop-gap because most modern systems are completely riddled with things like infoleaks, and you only need to leak one pointer to actually defeat the setup completely.
The real vector that's sitting around to be killed is control-flow based exploits (e.g. ROP, simple stack smashing, vtable ptr overwrites, all those de jour exploit techniques). You need a powerful form of control-flow integrity to stop this at the software level. You also need a method to actually help mitigate information leaks so they can do less damage, and increase attacker cost (e.g. "execute only pages" are worthless if all users have the same kernel image. I can just download your GENERIC kernel elf image, and just find the opcodes to do e.g. a ROP attack anyway. grsecurity uses compiler plugins that randomize kernel stacks and the compilation method with a particular private seed, at compile-time, so every compiled grsecurity kernel is different from the last one).
TBQH: FreeBSD is probably better off copying the other twenty gazillion exploit mitigation features from grsecurity that can reasonably stop exploits, even by themselves, dead in their tracks - like UDEREF, KERNEXEC, refcount overflows, triggering the kernel on unmarked signed overflow, the compiler plugin features, etc. Those will actually ban classes of exploits outright, every time, and always work, without wasting time through lots of wincing over the finer details, like ASLR.
You won't get to parade "look at our weak ASLR implementation!" (thankfully), but I feel we already have enough of that going around.
[0] https://www.openbsd.org/papers/bsdcan08-sensors.pdf
[1] I attended the BSDCan this was presented at, and sat close to phk and witnessed the exchanges about the technical merits, problems, "'good enough' vs 'good'", but am recalling from memory.
[2] Poul-Henning Kamp, https://twitter.com/bsdphk
I'm not talking about Linus. Linus swears, I think that's almost OK. No, I'm talking about the people who go out of their way to be unpleasant. Some of them swear too, but saying fuck isn't the heart of what makes them bad. And I wish Linus wouldn't swear — he attracts too much criticism and shields people who could use a little headwind.
I'm going to donate to freebsd just for that.
Maybe at some point one of the BSDs will implement a new, cleaner init system.
There's a new version of nosh ready on the new WWW site. I'll be announcing in the usual places soon. I believe that it has a few things of interest to people, including (given what was said above) a slight further extension on the cross-platform front.
URL: https://jdebp.eu/Softwares/nosh/
> It has moved. There's an article on the new WWW site about what happened.
Can't find the article though.
That's not the nosh 1.28 announcement, by the way. I have yet to do that.
> That's not the nosh 1.28 announcement, by the way. I have yet to do that.
Okay, will that include the "article on the new WWW site about what happened"?
As I said, it's on the new WWW site, and you can read it there.
For want of a better place, I put it on the new WWW site in the "author" section. For now. The change of WWW site motivated me to do some restructuring of things that I laid out decades ago and tidy up stuff that was only there for some old URLs that were floating around (that don't point to the new WWW site of course, making the fixes for them irrelevant). I still haven't settled on the layout of the "author" section, and it might change. Any URL valid now might not be valid in months and years to come when this comment is still visible to the world. And I have just been tidying up the long-term consequences of stale URLs on discussion fora from years ago.
So just follow an author hyperlink, from pretty much any page, to the (current) author section and proceed from there.
(I know these topics can get quite heated, but I'm genuinely not looking to start a flame war).
While systemd clearly helped consolidate and make administration more predictable across linux distros, there are deficiencies and regressions due to systemd which for the most part didn't exist in the pre-systemd era. It may be due to the scope of functionality systemd aims to cover, but some of the unconventional or missing command line options don't help either. However, it's used by enough mainstream distros that I expect the kinks to be fixed with time.
I was more interested in why the OP didn't consider FreeBSD to have a "useful init system". Just wondered if it was a preference thing or if there were features s/he considered it to be missing or were perhaps unaware of.
I keep seeing this argument, and i keep wondering what it is actually trying to say.
Just about the only time i can think of that i want to spin up a daemon in response to hardware changes would be with a USB bluetooth dongle, as it would require certain daemons to get working.
But the cost of just leaving a deamon idle in ram seems much lower than having to engineer a whole new init that monitor /dev changes so that it can start or stop a process or two in response to them.
Then again, maybe i am not the laptop packing dev convention goer that seems to use their laptop more like an oversized phone than a laptop (never mind a desktop).
Edit: damn keyboard ignored the copy command somehow, so i had the wrong quote pasted...
Funny enough, FreeBSD is handling runtime hardware changes neither in its init process or rc scripts. Instead the FreeBSD kernel has a single-reader device event channel, which is read by devd. The submitted events range from ACPI laptop lid close/open, to added usb things or ZFS errors. They are matched against configurable rulesets and their respective actions executed. Loading kernel modules, starting daemons etc. Devd also multiplexes the received events to arbitrary numbers of additional consumers via a number of available sockets in /var/run.
Could you eloborate where you had problems? The BSD init system is already quite clean, much cleaner than sysvinit.
I'm not sure what systemd features you need but most if not all can be replaced by small unix tools - that's kind of the point of the BSD philosophy.
BSD init is pretty small and clean. I would argue systemd is much less so because of the large scope of the project. The more lines of code and features you have means there's going to be more bugs and more ugliness, and that's true for all large programs. New doesn't mean better either. If it isn't broken and still works well, then you don't need a replacement, which really is why systemd exists to begin with. Sysvinit was a god awful and byzantine program IMO.
Look at ports/sysutils/u-boot-cubieboard2 for a template on how to build a suitable U-Boot, and sys/boot/fdt/dts/arm/cubieboard2.dts for a template for your dtb.
For a detailed list of supported hardware, have a look at the wiki: https://wiki.freebsd.org/FreeBSD/arm/Allwinner
> Intel GPUs up to and including the unreleased Kaby Lake are supported
> Amdgpu AMD/ATI driver has been updated to GCN 1.1 and higher