I honestly have no idea whether you are supporting what was said with that link, or objecting to it.
Anyway, I was talking about being inquiring. When you look at that list, surely, some questions do rise. “Why should I worry about all of that to read three paragraphs of text on some webpage?” “Which actions have made it so?” “What should be done to fix it?” Right?
I am objecting to what you are saying. It's terrible advice and an obtuse vision of the complexity of software nowadays, especially web browser.
Yes, a 3 months old release of chrome is not suited to use day to day. I link all the known and published CVE on chrome, but if you want to nickpick you could "just" check those which start with 2023-*.
OK. Shouldn't we ask questions about real or perceived “complexity of software nowadays”?
Why does displaying a piece of information that would fit onto a single 80×25 text mode screen absolutely require exposing to a third party a potentially (and, as mentioned, effectively) vulnerable WebHID functionality (which is non-standard, and seemingly only exists to make ChromeOS less mediocre operating system), various WebGL libraries and wrappers, ever-growing Javascript and CSS engines, and thousands of other entities? Someone who grants the whole internet access to local service ports by not using a firewall is considered a fool, but at the same time “non-foolish” “security conscious” people start their browsers, and see no problem in all the services embedded in them.
Isn't relying on a constant (and never ending) stream of updates from white knights in the holy castle in the manner you describe just a subscription model without a defined price?
Who controls the Web? Is controlling the web client enough for that? What benefits the endless rat race might give to them?
How come there's a hidden dependence on corporate products and their support cycles even in the process of using seemingly “open” technologies, say, for government sites and services? Is “I have no idea, my code absolutely requires latest libraries” a valid excuse?
Can mindless acceptance and circular finger-pointing between web developers, library authors, browser developers, and users solve these problems? What needs to be done?
Those are all upstream bugs, not Arch's. That's the trade off when you're running bleeding edge, but you can't blame Archlinux for packaging a buggy application.
I'm no really blaming anyone, I'm thankful for Arch, I love it, and I recommend it to other people who ask (well, at least those that can handle it :)).
> Those are all upstream bugs, not Arch's.
IIRC the grub issue was in the update script, so it may have been an Arch bug rather than an upstream bug?
Still, it would also be nice if a package is known to be broken due to an upstream bug it would get rolled back, so once the breakage is known, no one else will update into a broken state. That would save some time over each person individually updating to a broken state, debugging for a bit and then downgrading the broken package and then also paying attention not to reupdate it each time they update the system until the problem is resolved.
But again, not trying to complain or assign blame, I was just responding to a question in a parent comment.
Even the first argument "no hidden control flow" is disingenuous :
either the object you are summing are complex and you have to call a custom function to define what "summing" means in that case (you need to provide the summing function), or those are a primitive type and you're just calling a function builtin the language itself. In every case, you are calling a function ...
> or those are a primitive type and you're just calling a function builtin the language itself
You’re thinking at a different level of abstraction to the Zig developers. Summing a primitive type is going to be turned into a couple of machine opcodes (but no branch instruction) and will usually be constant time, whereas an explicit function call will require pushing pc to the stack and jumping elsewhere, executing any number of instructions once there, taking an arbitrarily long time, making it more difficult to reason about.
A better way to think about it is: for a given line of code, how much context do you need in order to understand what function is actually going to be called? Yes, some compiler-rt or soft-fp function might get called but you know that's happening and what it does.
With most languages you need significantly more context than you do in Zig - in C you need to know what preprocessor shenanigans might be going on; in C++ pretty much anything could be happening (operator overloads, virtual functions, constructors, destructors, who knows what else). With Rust you need to know what traits are imported, and if proc macros are involved then anything goes.
So few people actually do their development/testing in truly-sandboxed environments that I don't think that there's actually much of a difference in practice between malicious code running in userspace vs malicious running in kernelspace ( https://xkcd.com/1200/ ). Of course, I'd love if sandboxed dev environments became more usable and widespread.
On linux, i like peek[0] quite a lot. Its ui is straighforward, and it can export to gif, webv and mp4. However it's only compatible with X11 as far as i know.
Thanks for that resource; I've followed other "recommended" guides before and have a drawer full of mediatek and atheros based dongles that don't work reliably for me. Strangely enough my best experience (the b/g/n mentioned in my first comment) uses a realtek driver that is (or at least was at the time) out-of-tree, and it's made by TP-LINK which is generally recommended against because there is little correlation between part-numbers and chipsets used...
You can also use pycparser[0]. It is fully compatible C99, but be careful it doesn't support gnu extensions (like attributes, #indent, asm() ...). You can however work around most of them by -D defining them to empty macro in the argument.
Right, pycparser is what CFFI uses. I’ve seen some really cryptic error messages when it tries to process some of my C header files (since worked around), and I’m curious what else is out there. The ability to preserve info about formatting that the OP noted is especially interesting.
As long as we’re on this tangent, here’s the challenge I’m facing with automated analysis of student code: from foo.c make bar.c which is identical to foo.c except that comments have been turned into spaces. I think this is annoyingly non-trivial.
To remove comments from source all you need is a tokenizer.
You don't need all the tokens, just the "preprocessor tokens". For instance
literal strings, ppnumbers ...
Then /comments/ can be replaced with 1 space and //comments by \n
Multi-line comments would need to be turned into multiple blank lines, but yes, thank you for pointing out that I've been over-thinking this. I will look into what is the path of least resistance for this tokenizer-based transformation.
