Mozilla started working on a similar API with Facebook back when Google announced FLOC. They are most likely more opposed to the bad press FLOC got than they are to the idea itself.
> They are most likely more opposed to the bad press FLOC got than they are to the idea itself.
I'm not well informed of how Mozilla is run, but isn't it just a business? Does it have any consistent values? I would assume that all decisions made by Mozilla are a balancing act between money and pr.
Most users only bother with quick solutions for whatever problem they have, not with any deeper understanding. They get the kind of expertise where the BOFH only has to sit on the sidelines with a bucket of popcorn, watch the user shred their own system and offer a pristine replacement with all their local data gone.
The amount of times I have seen users click past pages of apt install ouput after messing with the package sources has been well above zero.
> because of the part on how local phone rates went up when AT&T was broken up.
Isn't that caused by the "last mile" problem? Even with the split there was always only one company in control of local infrastructure and from what I understand they could even block newcomers from installing their own, citing concerns over possible service interuptions and various kinds of interference. I think Google Fibre even went through several experimental ways to get its infrastructure in place just so it could avoid dealing with any of that.
> All of these are talking about security issues, not "acting differently".
Because no system has been ever taken down by code that behaved different from what it was expected to do? Right? Like http desync attacks, sql escape bypasses, ... . Absolutely no security issue going to be caused by a very minor and by itself very secure difference in behavior.
Googles privacy policy once listed it as a way to manage the privacy impact of its services without going into detail what that actually meant. They reworded it around the time the lawsuit came up.
> I doubt that it would cut down on the amount of low effort garbage.
Right now the main search engine everyone uses is run by an ad company. Just getting rid of that conflict of interest would probably help to significantly weed out garbage.
There is a difference between an API promissing that a value wont be null and a buggy program setting a null where it should not. A reference is only null if someone fucked up. As a programmer you can usually rely on a reference not being null and you couldn't do anything about it if it was anyway within the constraints of the language.
no, deferencing a null ptr is UB. An enum class outside the declared values is perfectly valid.
You could design a language feature where integer to enum is checked, but that's not enum.
Enum classes already add scoping, forbid implicit conversions and allow explicit underlying types. Those are pure extensions. Making undeclared values invalid or UB would be very surprising to people used to normal enums.
> if only for the fact that a round-trip toUpper().toLower() will not give you back the original word.
It is an inherently destructive round trip, especially in a language that makes excessive use of upper case when comapred to english. When you have the word "wagen" did it originally refer to a "car" or did it refer to someone "trying"?
I'm not a German speaker but this is definitely not exclusive to German nor is it caused by 'excessive' capitalization. The use of capital letters to denote nouns only helps to disambiguate it in German. While in English, this distinction is never clear just from the spelling of the isolated word alone. E.g. 'contract' can either mean 'an agreement' as a noun or 'to decrease in size' as a verb. There are plenty of other examples.
I agree though that this makes the round-trip inherently destructive.
> likely a regression introduced by a rhel-specific patch. Blaming crowdstrike for this is stupid (just like blaming microsoft for the crowdstrike bsod is stupid).
Yeah, it isn't as if crowdstrike was specifically advertising certified support for RedHat Linux and related products.
Back in The Good Old Days, an OS vendor would release a beta version and software vendors would test against it and fix problems before the stable OS version was released.
Obviously OS updates come out a lot more often these days than they used to - but we're also better at test automation than ever before, and beta software is easier to get than ever.
It sure would be nice if companies that decide to produce kernel modules and to support certain OSes could test those kernel modules against those OSes at the beta stage.
1.An eBPF probe is not a kernel module. An eBPF probe should never cause kernel panics.
2. RHEL didn't provide beta kernels before very recently, as far as I can tell.
3. Even if you caught an error then, you're still at the mercy of RHEL to fix it. If RHEL breaks a feature, you report it to them, and they decide to ship anyways... well, your product will still kpanic. I'm not talking hypotheticals: I haven't seen RHEL do that, but I've seen other distros do it.
Should, but did. This is the point at which to learn and adapt.
Also, kernels are software just like nearly everything else, and software is buggy. It's a balance obviously, but some basic defensive development can be a real savior for your users.
I don't know the details about this CrowdStrike incident, but I would also be surprised if you couldn't write an automated test (even a "smoke test") to quickly test out these new kernels before they hit your customers. Given what happened, it seems like negligence not to do that.
It's possible CS can do better, of course. But it's just wrong to blame them for the Linux crashes - they're not the ones that introduced buggy code and broke their users. RHEL/Linux did.
1) Those Crowdstrike unit files aren't ebpf probes, so the whole subject of ebpf probes is irrelevant here; or
2) They're obviously able to stop the rest of the kernel from even booting up (as Crowdstrike so convincingly demonstrated millions of times over[1]), so yes, they do indeed have at least as much power as any other bit of the kernel.
Either way, hunting around for nits to pick is a bit pathetic.
denial of service is not the same thing as arbitrary code execution, and that goes double in kernel mode, but yes, it does seem that the linux implementation of ebpf had buggy sandboxing; i don't think allowing clownstrike to prevent booting was part of the intended objective
i wasn't hunting around for nits to pick; i was hunting around to see if you'd ever contributed any useful comments to the site. instead i found you making authoritative pronouncements about ebpf that were so wrong that you had evidently never read so much as a one-line summary of what ebpf was for. do you have a more promising historical comment to offer? perhaps something where people complimented your contribution as being informative?
have you ever made a worthwhile comment on hn?
on thursday, wahern posted this comment https://news.ycombinator.com/item?id=41061179 where they traced through the illumos/opensolaris source code to track down how a peculiar solaris interprocess communication mechanism worked, an investigation i had started but gotten stuck on. why can't you make comments like that instead of harassing me about how i format my comments?
the reason i'm asking is because i'd like to be able to talk to more people like wahern, but most of them avoid this site. a major reason why is that comments here frequently receive vacuous, aggressive responses like the comment you made the day before in https://news.ycombinator.com/item?id=41056718, where you launched a personal attack on me because you didn't like how i was formatting my comments
i'd like you to ⓐ apologize for doing that (this is not the first time you've done that to me personally; so far i haven't looked through your comment history far enough to find out how many other people you have a history of repeatedly harassing) and ⓑ commit to not doing it again
because i'm sure you're capable of making comments that make the site better instead of worse
> do you have a more promising historical comment to offer? perhaps something where people complimented your contribution as being informative?
> have you ever made a worthwhile comment on hn?
I might answer that. If I thought you were owed any justifications from me. Which I don't.
And no, I'm neither “harassing” you nor being “vacuous, aggressive”. This isn't ad hominem, it's ad habitem. You write here for other people to read, and I'd even appreciate many of your comments -- if they weren't so infuriatingly idiosyncratically formatted as to disrupt fluent reading. Have the fucking courtesy to write like a normal person, and you'll be treated like a normal person. To begin with, get the shift key on your keyboard unstuck so you can start your sentences with capitals. And in case your dot / period / full-stop key is totally gone, copy-paste some of these: ........... So you can end them properly too.
Because I'm sure you're capable of making comments without coming off like an illiterate buffoon.
And yes, BTW, you totally were. Careful now, you don't want to end up like chockablock again, do you?
Yes, and? They probably do test their software on RHEL.
But how are they supposed to prevent a bug in a newly released kernel update? You can't test your software on future updates that aren't out yet.
If RHEL breaks some core functionality you depend on, in a newly released update, you can't really do much to prevent breakage, even with the best QA in the world. At best, they could have caught it as soon as RHEL published the new kernel... but by then it's already too late, all your currently-deployed probes now have a ticking time bomb, and need to be updated before the RHEL kernel update is applied, lest you kernel panic.
Maybe by not loading the module into unknown kernels in the first place?
If say you support a distro, you can’t turn around and complain that supporting the newest version is hard, no matter who caused the problem. Plenty of products say ‘this works on $x but it’s not officially supported’.
If you expect software to be future-bug-proof, well, I guess you live in a far better world than I do.
If you advertise your software to be compatible with RHEL, but a glibc bug gets in and causes your sw to crash for a couple of days, before RHEL realises the problem and fixes it, does that mean your software should instantly no longer be advertised as RHEL compatible? That'd make things a lot more confusing, if you ask me.
Not all eBPF programs are compile once, run everywhere.
RHEL 'updates' can mean different things. A patch release won't change kernel ABI. A minor release will. Writing a non-CORE eBPF program for, say RHEL 8.6, might break on RHEL 8.7. It's not advisable to update across minor releases without lots of testing. Most of the time, things 'just work' but RHEL is a very complex product with a specific support cycle, and laziness of users and 3rd party vendors is not their fault.
This was their newer eBPF falcon sensor that was trying to load a bpf program in the kernel and triggered kernel panic. This shouldn’t have happened and was definitely a bug in the kernel.
For the kernel mode, their software will flag an unknown kernel as unsupported and go into a reduced functionality mode (rfm).
The idiots didn’t know that RH E4S was a thing for like 3+ years.. I’m still baffled by how clueless most of the security people and vendors are when it comes to backporting and different streams / channels that are offered by multiple Linux OS vendors.
> Maybe by not loading the module into unknown kernels in the first place?
Then you better tell your customers not to `dnf update` until you've had a chance to whitelist the new kernel and ship it in your own stream. Otherwise everyone who updates before you do ends up broken. If a vendor told me that, I would laugh, realize they were serious, thank them for their time but let them know that we will be going a different direction.
reply