M-x untabify ? ;)
1,578 karma · joined August 13, 2012
With UNIX, the integration platform is the shell, hooking simple specialized tools through pipes and the shell language.
With Emacs, the integration platform is a Lisp environment, hooking specialized Lisp tools and Unix tools through Emacs buffers (or buffers regions) using the Elisp language.
So it's an extra layer, but if you look at it in this way you can see similarities: an environment that makes it easy to compose elementary functions into an integrated whole.
In both cases, it's most suited for people who are ready and willing to build their own specialized environment on top of a powerful platform. Although many users don't and stick to the basics too.
https://opensource.googleblog.com/2021/04/logica-organizing-...
In short, it's easier to compose (and decompose), which helps with complex queries that can be assembled from simpler, independently tested parts.
No personal experience in this, I just remembered that blog contrasting Datalog and SQL.
Funky macros can still make static analysis more complex by introducing layer(s) of indirection of course.
On the device (dGPU here), it is possible to route memory accesses to part of the internal address space to the PCIe controller. In turn, the PCIe controller can translate such received memory access into a PCIe request (read or write), in the different PCIe address space, with some address translation.
This PCIe request goes to the PCIe host (CPU in a dGPU scenario). Here too the host PCIe controller can map the PCIe request, using using a PCIe address space address, into the host address space. And this can go to the host memory (after IOMMU filtering and address translation usually). And all this back for the return trip to the device in case of a read.
So latency would be rather high, but technically possible. In most application such transfers are offloaded to a DMA in the PCIe controller doing a copy between PCIe and local address spaces, but a processing core can certainly do a direct access without DMA if all the address mappings are suitably configured.
Works for me, started during the Covid "at home" period and continuing since then. Complete and no-nonsense. It's illustrated with pictures of body building champions but no worry, it's fine for normal people like me too ;). There are different programs for different levels.
If you don't want, or can't, do the job of a system integrator for your PC, you can now buy PC with Linux pre-installed. Or use another pre-installed OS.
You may think installing Linux on a machine is not a big deal (and I'd agree as far as I'm concerned ;) but it's clear it causes a lot of grief and frustration for some.
If you're new to Linux, please get a pre-installed PC. If you want to install Linux on a PC, be aware that the integration is on you. So start easy: well supported models (Thinkpad, Latitude), stick with integrated graphics, be careful about new models particularly with big changes (e.g.: the recent new "soft" webcams), and in general do a bit of research before so you can get confident you can deal with it.
I've read somewhere that the "full Z3" mode with `--z3` is very experimental and not well maintained. It didn't crash when I tried it but was no better and way too slow: typically 15 times slower on average, but a few files took over 24 hours to check.
No, I just picked it from the ENS web page (https://www.astree.ens.fr) but it may have not been updated for a while.
As I understand it there's been improvement on dynamic allocation with separation logic in general, TBC what Astrée supports (I've no first hand experience).
For recursion, it's a similar problem as for loops as I understand it: to handle it fully automatically the analyzer would have to prove recursion terminates and find and prove induction invariant. But safety critical code tend to forbid it anyway so it may not be a big limitation for most Astrée customers.
> I have done some preliminary testing with this on the OpenZFS codebase and I am less than happy with the result [...]
A question: have you verified that the Z3 support is enabled in the LLVM toolchain you use for Clang SA? It is in Debian Bookworm, but not in Buster, and from memory I don't think it is for Ubuntu 20.04 (LTS) due to a packaging snafu.
I would expect the lack of Z3 support to lead to a lot more false alarms in a FS, as the analysis with only the Clang SA build it range analysis will be basic and won't understand anything related to bit fields and operations for example.
The `llvm` package must depend on a `libz3-4` package, recent enough (on Bookworm it's 4.8.10, but IIRC anything >= 4.7 would be used). Another way to check could be to use the CodeChecker `--z3-refutation`: this is enabled by default if LLVM has the Z3 support, but if requested explicitly should fail if not (untried, TBC).
I'm definitely not an expert but look into SA a bit out of curiosity. Sound analysis normally comes with significant restrictions. For example Astrée does not support dynamic memory allocation nor recursion (not too bad for embedded). There's likely more.
Let's consider the case of an iteration, with a number of loops unknown at compile/analysis time. What an unsound SA will typically do is unroll the loop a fixed number of times (5 by default for CC/ClangSA from memory). Obviously this could miss bugs if less than the actual number of loops.
To do better, a fully automatic sound analyzer would have to derive the relevant loop invariants and the associated induction proofs automatically, not to have to make any guess on the number of iterations. As far as I know this is still a research topic. Or alternatively, enforce a known, small enough bounds for any loop.
In general, either the sound SA must be able to derive quite complex proofs for the characteristics to enforce (research topic), or it must enforce simplicity to make the problem manageable automatically.
An alternative is a tool like frama-C that can kick the ball back to a human, to do the correctness proof manually using a proof assistant for automatic verification, if automation fails. And that can be a hard job.
The more constrained the application, the more realistic sound analysis should be. I don't know where a filesystem like OpenZFS sits here. Best of luck in any case!
I use CodeChecker with ClangSA, CTU enabled and with Z3 for refutation. The code base is smaller so incremental checking is less a concern to me.
Still, we had a look. CC allows taking a list of files, and updating those files analysis only while keeping the existing results for other non listed files.
But unless something has changed this partial analysis just do what it's told, analyzing only the files given on the CLI. With CTU this may miss side effects: a modified file may impact other files using its function for example. It's possible to use CC own CTU info to derive these dependencies and extend the list of files.
Then there are modified header files, with the usual inclusion dependencies.
So if it's not provided "out of the box", it should be possible to have a layer on top taking a list of changed files, extending it with both CTU and header dependencies, and passing the extended list to CC for a safe update.
I don't have any experience with Coverity, but used another commercial static analyzer (SA) that I won't name in case there are similar legal limitations as with Coverity ;)
With the commercial tool I have the same problem you mention: too many false alarms. Most reports are a waste of time really. In the end, people tend to ignore the tool.
The best results I get with Clang SA, used through CodeChecker. Very few false alarms, and usually at least code smells. It's not sound of course, but is free and could spot a few nasty bugs. I recommend trying CC+ClangSA.
One important point is the ability to do cross files analysis. It is very common to use a value from a function in another file. With a "one file at a time" analysis no assumption can be made on this value range, so the analyzer must be conservative. This leads to a lot of false alarms in practice.
With cross file analysis (called "cross translation units" or CTU analysis in Clang SA), the SA can propagate constraints along paths traversing multiple files. This makes a huge difference in my experience. As I explained in another comment, this is well suited for an application: all paths come from `main`. For a library the result will depend on the test application(s) provided to the SA: the call to the library under test must cover all the function domains for the analysis not to miss some issue. Otherwise, it may use too restrictive constraints from the UT that are not relevant to real life use.
But it may not be enough: the commercial tool I use do make cross file analysis. It seems more limited than Clang SA though, and misses a lot.
Another thing that help IMHO is the use of Z3 as a checker. ClangSA uses a simple and fast range based analysis. As far as SA goes, this is a bit primitive and not as powerful as polyhedral analysis for example (which is more expensive).
But when Clang SA range analysis finds an issue, it is cross checked with the Z3 SMT solver, which can deal with more complex constraints, and possible rejected there. I do embedded development, and Z3 can understand bit fields and bit operations for example (trivial for a SMT solver with bit vectors). I never tried with and without using Z3 in this way, but I assume it helps.
In any case, I'm very happy with the results I get from ClangSA+CC with CTU and Z3 enabled (check your LLVM toolchain for Z3 support, OK in Debian stable for example). It's much better in practice than the costly commercial tool we still use, for now.
For cross compilation, there may be a few Clang/GCC differences to work-around. CodeChecker already handle some, but maybe not all. It's been manageable in our case. For Linux based development CC should work fine out of the box.
The Clang static analyzer [1], used through CodeChecker (CC) [2], do support CTU (enabled with `--ctu`). I'm very happy with the result on the code I'm working on.
Of course this is not magic, and it's important to understand the limitations. The CTU analysis is well suited for an application: there is a `main` function, and all the paths from there can (in theory) be analyzed through the code base files. But if the code to analyze is a library, then the CTU analysis will be done from one or more unit test applications and the paths constraints analysis will only be as good as the unit tests. To avoid this one can analyze without CTU, but then the above code will always trigger a report as the static analyzer has no information on `some_function` return value and must assume the worst.
The other limitation is that there's only a limited complexity budget the analyzer can handle, so it cannot track all constraints on all paths. Depending on how the approximation is done it can lead to missed detection or false alarms.
IKOS (last time I checked) does not support CTU, it's doing "a file at a time" analysis. As far as open source tools go the Clang static analyzer is the only one I know with a working support for CTU (best used through CC). I there are other ones I missed I'd be happy to learn about them and try them out.
Clang SA + CC is a really nice combo. It's not sound (the limited complexity budget above), so can miss issues. Still, with CTU and the use of Z3 to cross check alarms (very nice when using bitfield) it is a nice user experience with very few false alarms, which matters to make the tool more acceptable (people tend to ignore tools with too many false alarms after a while IME). Still some rough edges for people doing embedded cross compiled development but manageable.
[1] https://clang-analyzer.llvm.org/
[2] https://codechecker.readthedocs.io/en/latest/Really nice when you made changes elsewhere and realize late that you made a mistake (but not too late: the undo info must still be present of course).
Emacs is best understood as an editor construction kit with a default editor as an example. It's a "build your own editor" Lisp environment. And it's really more "text based applications" rather than just editor. Add some support for images and SVG on top too, although it's not as central as text.
Nobody fully build its own Emacs variant of course, there's a lot in the core Emacs (with a surprising amount of features disabled/hidden by default!) and it's most of anyone Emacs variant. Still, the approach of putting up one's "own" Emacs is important. I'm using over 50 packages, with a ~100 kB init file and Emacs distros are way above this I guess. The basic experience is if I want something to work some way, I'll look for supporting package(s) and tune them as I want, or much more rarely write some Elisp.
Making Emacs more approachable to newcomers is a recurring discussion in the Emacs world. For historical reasons there's a barrier, as Emacs predates a lot of things (GUI windows so in Emacs a "window" is what's a text pane in other editors, Ctrl-X/C/V so it's C-w/M-w/C-y in Emacs, etc.). Changing this would be disruptive to current users, and Emacs puts a lot of weight on being backward compatible. It's not possible to please everyone here.
In the end, I don't think Emacs "alieness" is a problem. The differences are rather superficial and easy to learn (with some motivation). For people not interested in this, there are plenty of alternate editors that focus on being user friendly, and it's perfectly fine. Choice is good.
Much more important to the Emacs experience is the ease of customization and adaptation. The Lisp environment is a big part of this: once you know the basics the embedded documentation is very extensive and always accessible. It's trivial to get the documentation on any function or variable, and go to its source code. It's also straightforward to adjust any behavior. There is no difference between core elisp code and the user code. Changes to the core are done in a conservative way to avoid breaking all the current users customization (there are breaking changes, but with early obsolescence warnings and good change documentation). All this is a much more important part of Emacs than the early experience. It's also quite specific to Emacs, I'm not sure there are many alternatives? If any, they're also "not so user friendly" (like neovim with Lua now?).
In summary, there's a tradeoff being first user experience, backward compatibility with such a long history, and flexibility to accommodate very different needs and use-cases (some of them incompatible). Emacs has a specific situation here. It may not be to everyone taste, but it's OK: there are plenty other alternatives. There's a thriving community, improvements have never been as speedy. I'm a happy user seeing no reason to change, on the contrary: I really feel it's getting better and better!
In both cases the printers support IPP (the Internet Printing Protocol) and are advertised on the LAN, either natively at home or through a print server at work.
I've never digged much into this, but I believe the combination of zeroconf (for the printers discovery) and IPP are the key elements for CUPS to provide this seamless support. The printers just show up in the my KDE settings, and their settings are exposed in a reasonable way through configuration dialogs. The ink or toner levels are even visible.
This is on Debian stable, so I would assume most distros are at this level now.
With a manual stock distro installation maybe, as the defaults are very conservative. But just install the "tlp" package (the laptop project) and the situation flips. At least that's my experience at work based on Dell Latitude laptops and Thinkpads T before. My battery life is way above my Windows using colleagues, and my fans are mostly off (unless big compilation or test runs) instead of mostly on. Of course it's very likely due to the anti-virus, but that's part of the corporate Windows experience nowadays.
The sanitizers (UB, address, memory, threads) are supported by both Clang and GCC [1]. Yes that's up to 4 different builds and tests runs but with an automated C/I this is not a big deal.
The Clang static analyzer, with Z3 enabled as a checker, used through CodeChecker [2] is now very good, so much so that I prefer it to a different commercial product showing too many false alarms. Using it on an embedded GCC cross-compiled code base may still require some workarounds, but nothing too bad and this is improving regularly too.
I wouldn't want to do without this. Switching to Rust may not always be possible, and there are big C and C++ code base that will live a long while. Tools like this help and they should be used.
If one reads the Common Criteria specifications [1], they actually require obscurity at some level (didn't check which one, for sure EAL4 and above do). Specifically, all the design must be kept secret so obscured to attackers. This is serious stuff, requiring secure design facilities for example. The goal is to force an attacker into a complex (so costly) reverse engineering.
There is a too common vision of security as an absolute thing, it's either secure or not. This is already a simplification for algorithms, but there why not. But for secure systems it's definitely not sufficient, and you agree with this like GP does it seems. Professionals must balance the cost of security vs. the cost of an exploit. And obscurity do raise the cost of an attack, so it makes perfect sense to consider it. And it is considered (see CC).
So GP summary that obscurity is justly considered by professional, and makes sense as long as it's not the only defense, seems correct to me and worth mentioning. You have taken it as a criticism but you shouldn't: it essentially also says what you said, that obscurity has its proper place in security.
But inside a controlled environment like a datacenter, it works. It's been used in the telecommunication world to carry control messages in the radio access and core networks for example. So it's been tested at scale for critical applications.
[1] https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
What you list is either analog of older nodes (~90 to 40nm). It's a very different world, with often different players. TSMC plays in the digital old nodes, but as I understand is not very motivated in investing in much new capacity, and try to push customers toward 22nm ULP (may work for some, but not all). Others are investing, but it takes time.
So you start to see a glut at the high end, but still constraints in the analog / old nodes.
1) A simple interface, with good discoverability (options and functions shown);
2) Good visualization and operations on the current state, with work tree and index, in a simple and intuitive way.
People often complain about the CLI interface, but for me (2) is also important. Having a compact, simple representation of what's changed in the work tree and index, and easy manipulation, is important to reduce the cognitive load. No need to keep track of this in your head, just look at the Magit status window.
Yes, "Fanboy's Annoyance" list under the "Annoyance" section, in uBo "Filter Lists" configuration tab. I enabled it recently only, and so far it looks OK with IDCAC removed. And uBo is also supported on Firefox for Android.
This list is not complete, KDE konsole supports this too (and other formats) for example.
Let's say that the heat energy of the warm thing is "E" and the outside and fridge are at same temp for simplicity. Let's also assume that the house is not heated using a heat pump.
Consider the two cases:
1) The warm thing is put into a fridge. It's a heat pump, with coefficient of performance C. To cool the thing the fridge will consume E/C, and E will be released as heat inside your room. So you paid E/C of electricity to get E Joules of warming in your home;
2) The warm thing is put outside. The energy E is wasted outside, and then the piece put into the fridge with no extra cooling there. No energy spent by the fridge, but no warming of the house either. To do a fair comparison with the same final state, we need to add E joules of energy to heat the house, which will require E Joule of electricity or primary energy (because no heat pump to heat the house).
So to reach the same point, in case (1) we spent E/C of heating energy, and E in the second case. It is indeed more efficient to put the warm thing directly into the fridge, as this will contribute to heating the house with the efficiency of a heat pump.
And if you heat your house with a heat pump of same efficient C, you don't care either way: it's equivalent.
But chiplets are actually first for cost optimization, and second for process optimization IMHO.
The first cost optimization is to leverage the better yield for a small die compared to a monolithic die. The density of defects for a given process means that N small chiplets will be cheaper than one monolithic die with same number of cores: one fault will kill the whole monolithic die where it will kill only one chiplet. A SoC only uses good chiplets ("known good dies" or KGD is the term of the art). That's what has driven AMD too chiplets in the first place.
The process optimization can also be for cost saving more than performance: if an older node is acceptable, it's cheaper.
Then there is the design saving, and this shows up in Intel chiplets presentation: by developing M CPU and N GPU chiplet variants for example, one develop M+N tiles but by mixing and matching can offer MxN SoC. One has to add the chiplets interconnection complexity (extra work vs a monolithic design), but this may still save on design development. And design development costs increase a lot with each new node.
Chiplets may also become a way to extend the life of a design. We may see at some point chips embedding a mix of "old" and "new" chiplets. This could extend the useful life of a chiplet design, and give more time to amortize the increasing design costs.
So I guess a good way to see chiplets is as a cost management tool first, in the face of ever increasing design costs on advanced nodes. With the nice side effect that they also open the possibility to optimize the process per tile, if needed.
With a chiplet standard and the possibility to treat chiplets as silicon IPs today, a chiplet target market may be extended too. For example Intel as a fab may sell its chiplets (or part of their catalog) to their fab customers. This is yet another way to absorb increasing development costs, but we're not there yet.