I can now confirm: Emergency cell broadcasts do work in spain! It would be nice if they weren't exclusively in spanish though... (edit: not -> now.)
Remote
Martin Uecker
@uecker@mastodon.social
mastodon 4.8.0-nightly.2026-10-06Computer Science and Biomedical Engineering
Graz University of Technology
Full professor for biomedical imaging and head of the Institute of Biomedical Imaging at TU Graz. I do systems engineering for magnetic resonance imaging. In particular, I work on the low-level real-time software that controls the behavior of nuclear spins at nanosecond resolution and on the numerical algorithms that compute images from the acquired data. I support open science and free software. Opinions are my own.
351 Followers
375 Following
50 Posts
Joined October 28, 2022
Institute of Biomedical Imaging, TU Graz:
Today I ran a model checker (cbmc) on a sudoko solver to prove memory safety. Certainly a toy problem. But now I know my sudoko solver is verified to be written in memory safe C. Who knew this can be so simply? (I do not expect it to be that simple for real programs, but the underlying technology for sure is mature enough).
Replying to
@AwetTesfaiesus@mastodon.social @vicgrinberg@mastodon.social Aus der Wissenschaft gibt es schon sehr viel Kommunikation an die Allgemeinheit, und auch die Aussagen zum Klima auch sehr klar. Das Problem hier ist dass gerade in diesem Bereich die Kollegen ja massiv angegriffen wurden. Es ist ein gesamtgesellschaftliches Problem für die Anerkennung wissenschaftlicher Erkenntnisse zu arbeiten und die Wissenschaft vor politisch motivierter Einflussnahme und Angriffen zu schützen.
Looking a bit more into FPGAs... Made me realize again what blessing to the world gcc was (and is).
I can't buy a train ticket with Deutsche Bahn because "my browser acts like a bot". Would be nice of something just works for a change.
Our paper describing a simple shield suppressing capacitively coupled electrical interference in low-field MRI is publsihed.
https://doi.org/10.1002/nbm.70287
@jupfi
#MRI #imaging #opensource #openscience
apt-get install clang-21
831 MB
Replying to
It took a while though...
https://reproducible-builds.org/_lfs/presentations/2014-02-01-FOSDEM14.pdf#page=5
Replying to
@hunger@floss.social @lcamtuf@infosec.exchange The operation was successful, but the patient is dead. The extra problem here was that the operation wasn't necessary as there were not much much memory issues in the first place.
Replying to
There are probably to main issues. One is my banking app (which I use only as two factor) and the other will be ID austria.
Replying to
@dascandy@infosec.exchange The startup screen is easy, you just skip signing into google accounts. One can install apk packages from a web browser.
Replying to
Two-factors app one can get, email app as well...
Replying to
@gregkh@social.kernel.org @icing@chaos.social @joshbressers@infosec.exchange @wdormann@infosec.exchange @Viss@mastodon.social "it is not easy to decide who should be on the list, so we can not even have list with Linux distros hat should obviously be on list" argument seems rather unconvincing though.
Replying to
@rysiek The Chinese room argument is fairly unconvincing though. It would not be the person mindlessly following a rule book who can speak Chinese, but the system consisting of the rule book (software) and the processor (person in the room). Nobody would argue that a CPU / GPU is conscious either, but this does not logically preclude a computer with suitable software from being conscious. (no, I do not believe modern Chat bots are conscious, but they also do not pass a real Turing test)
Replying to
Replying to
@raymaccarthy @LinuxJedi Having switched from C++ to C, I do not believe C++ has any serious advantage worth its incredible complexity.
"... the addition `cap + bits_per_storage() - 1` wraps around to a very small value... This leads to an undersized heap allocation. ..." CVE-2026-44983
Replying to
@hunger@floss.social @lcamtuf@infosec.exchange Why should we not judge technical decisions based on technical arguments?
Replying to
@erisceleste @thephd hehe, that was what I was thinking about when proposing it on the reflector. But, can't you use the default branch?
Replying to
@synlogic4242@social.vivaldi.net @slava@mathstodon.xyz In my experience it not mental rigor that is needed but just applying some basic common sense strategies (.e.g. not open-coding string operations, having a plan about memory ownership).
Replying to
@hunger@floss.social Well, heartbleed was even in 2014 then a stupid error
https://web.archive.org/web/20140411014301/http://article.gmane.org/gmane.os.openbsd.misc/211963
Nobody guarantees that some "unsafe" added for performance does not bite you in the same way. Log4j was java, which came at some time I still remember with very similar promises about security as Rust.
Replying to
@hunger@floss.social @lcamtuf@infosec.exchange I am perfectly fine with people using Rust for whatever reason they may have. I push back against the idea that projects need to be written in Rust because of memory safety.
Replying to
@gregkh@social.kernel.org @icing@chaos.social @joshbressers@infosec.exchange @wdormann@infosec.exchange @Viss@mastodon.social I would imagine that the Linux foundation could assemble some experts that together agree on some objective criteria and a process and based on this organizations / projects are accepted to the list. Seeing such self-organization working in many other areas, I would expect that this is possible. But maybe there are reasons why I am wrong.
Replying to
@icing@chaos.social @joshbressers@infosec.exchange @gregkh@social.kernel.org @wdormann@infosec.exchange @Viss@mastodon.social All these arguments may or not be true, but I still do not quite see why - for copy fail - downstream open-source projects such as Debian were not notified during the embargo time?
Replying to
Replying to
@thejpster @LinuxJedi You could also use a length-terminated string type with bounds checking in C to write a parser. It is not clear to me why people don't do this more often.
Replying to
@krzk@social.kernel.org I think this is an unfair accusation. I was pointing out that the argument "it is unclear who to put on the list" by itself is a weak argument. I did not think that this needs further explanation as this seems obvious. Maybe there are good reason why it is difficult to maintain such a list, but the thread I commented on did not include those. In any case, I think it is not help to directly accuse people of "FUD" or misinformation in an evolving discussion.
Replying to
@simontatham@hachyderm.io @erisceleste@tech.lgbt @thephd@pony.social But I am not a fan of overloading. So I like to pass types explicitly and then it could look like the following. One can only pass typedef names, but this i not too problematic for my use cases.
https://godbolt.org/z/Pf7Tvjd81
Replying to
@hunger@floss.social @lcamtuf@infosec.exchange People can rewrite whatever they want, but I do not think one should encourage them. As this example shows, the exclusive focus on memory safety may be very misleading as their are many issues to worry about. There are also other ways to reduce the risk of memory safety issues in C/C++ and compared to them the advantages of Rust may be exaggerated. Rust also introduces new risk such as an ecosystem susceptible to supply-chain risks.
Replying to
@krzk You did not address my early point, which was that if development is mainly driven by specific parts of the industry, then it makes it more costly for others to contribute (in time or money). This is why I think the "you should just contribute" argument is too simplistic. But if you are saying it is still very easy to step up for volunteers with limited time and take over maintenance of a driver, then I am happy to concede that this does not apply to the kernel.
Replying to
@raymaccarthy @mansr @LinuxJedi i know that c++ has arrays, but only with fixed size which makes them unusable for most purposes.
Replying to
Replying to
@gregkh@social.kernel.org @icing@chaos.social I think the hostility "just a troll" is not necessary.
Replying to
@icing@chaos.social @gregkh@social.kernel.org Would you consider Debian, arch, gentoo, Redhat, Ubuntu to be worthy?
Replying to
@synlogic4242@social.vivaldi.net @slava@mathstodon.xyz Valgrind is an awesome tool, but we run it during CI and I can't really remember it catching anything in recent years.
Replying to
@simontatham@hachyderm.io @erisceleste@tech.lgbt @thephd@pony.social I think you want to switch on a pair type. Still needs hacks though.
https://godbolt.org/z/TGfefnYfM
Replying to
@krzk @kernellogger @klausman As i said, i agree in principle, but i think this is a bit too simple to only look at this from this perspective. The question is how easy / open it is for people to contribute nowadays. Following, using, and contributing to free software for a long time, this got much more effort for many projects, especially for newcomers. And I do not want to end up where the "entrance card" is being able to pay a kernel developer.
Replying to
@krzk@social.kernel.org @icing@chaos.social @joshbressers@infosec.exchange @wdormann@infosec.exchange @Viss@mastodon.social @gregkh@social.kernel.org I apologize for having expressed an opinion as a long term user and contribute to free software. I could, of course, try to explain a bit better why I have the impression that the free software world is a bit too much under the influence of certain tech companies and not as accessible to new contributors anymore, but your reaction tells me that there is probably not much point in having this discussion. (revised)
Replying to
@krzk @kernellogger @klausman People affected are most like not even seeing this discussion on the kernel list.
I am just generally concerned about the development that "free software" is now something shaped by north-american tech's interests, and I push back against the idea that everybody who has other interests should be able to afford to vest a substantial amount of time or money. But if this is not the case here and truly nobody cares, I am not at against dropping the drivers.
Replying to
@hunger@floss.social I am not complaining about people writing or rewriting things for learning. But canonical's motivation to invest in this project was entirely different and seems to be based on the false believe that this must be good replacement for GNU coreutils because it was written in rust. But also in general, I would encourage people to help with maintaining projects instead, because this is where the critical need is and one can also learn a lot.
Replying to
@hunger@floss.social I never had any of my C tools I use on a daily bash crash in decades (vim, kernel, terminals, bash, etc.), so I really wonder what C programs you use? Also C++ tools are in my experience very stable. I do not have much experience using tools written in Rust, but cloudflare's Rust code famously brought down the whole internet... Rust packages also come with limited security support in Debian: https://www.debian.org/releases/stable/release-notes/issues.en.html#go-and-rust-based-packages
So rust - so far -- made my security worse not better.
Replying to
@mirabilos@toot.mirbsd.org I don't know, what bugs are those? 97% of all packages are reproducible already: https://reproduce.debian.net/
Replying to
@mormund@mastodon.social Sure some of them would seem trustworthy. It might very well be impossible to create a perfect rule about who should or should not be on such a list. But this does not mean that one could not create some reasonable criteria and do a best effort. I disagree with "if you inform some of them you might as well inform everyone" Why should this be the case?
Replying to
@icing@chaos.social @gregkh@social.kernel.org Sorry about that, but I find the "nothing could be done" and "responsible disclosure" is dead arguments fairly weak and I do not think that pointing this out is trolling. But let's stop here.
Replying to
@raymaccarthy @mansr @LinuxJedi Isn'tt bounds checking optional in Modula-2? In C you can also turn it on. C++ had no proper array type last time I checked. It recently got mdspan which is still poor IMHO. C has an usable array type since C99.