isido

A link to the report: https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf

I have been involved in the same projects furthering open access within Finnish universities as the corresponding author has, and I think the aim of the study is not make OA look bad, but to make it better by finding its shortcomings and then fixing them.

This article is probably not aimed at Rust beginners and you shouldn't shy away from Rust, if you feel that you cannot possibly ever understand the lifetimes. The perspective of the article seems to stem from the author's own learning process, and might make sense only after you have some experience with the borrow checker and lifetimes. Most of the time everything might go smoothly, when you know the basic rules, but when the compiler gives you an error message, and you think it shouldn't have, then reading the article might give some insight on the problem.

And the Rust developers indeed deserve respect in my opinion too. They are trying to solve a hard problem and not taking the worse-is-better-option.

I think this is the published paper which contains the same vulnerabilites mentioned in the first link.

It is really nice when using mouse, but with trackpad, it is unfortunately not as convenient.

A good, but difficult question - it's difficult to quantize complexity. Both languages have aim that their users can have much as much control as possible, even if it entails complexity in the language desing.

Perhaps one answer could be, that much of Rust's complexity arises from the concepts of 'borrowing' and 'lifetimes' and how they are encoded in the language.

In C++, complexity much of the complexity arises from the copy/reference semantics, and the possibility of overriding standard behaviour. You need to have wider context to understand local code. So you need to understand how the C++ works on quite a low level and you might need to know more specifics on your C++ codebase than might be the case in Rust.

Generally, you need to know the operating systems and hardware work together. And then depending on the details, you might need to know C and assembly. In this case, you need to have good understanding on how modern processors do performance optimizations.

There probably isn't any good single resource for learning all this, but perhaps getting some good textbook on computer hardware architecture might be good next step after reading the "Code". Unfortunately I don't have any immediate suggestions on the current crop - I remember learning from William Stallings' books some 15-20 years back - not sure if they are the best choice nowadays.

In Poland, the ruling party (Party of Law and Justice) is a right-wing, populist party, which has tried to nominate/replace judges and to some extent, control the media. EU is has voiced concerns, but Poland's democratic processes still work, as evidenced in the recent recall of controversial abortion bill.

A Similar, but perhaps further evolved situation is in Hungary, where right-wing populists have held the power for quite a long. But even in Hungrary the rulings party's power is not absolute, at the moment, and you don't get thrown into jail for having wrong opinions.

Publishers probably cannot keep up with the current revenue levels, especially since the university library funding is constantly decreasing.

And besides Scihub, there are emerging institutional solutions to this problem, like research funders demanding that research paid with public funds must be publicly available, and universities setting up academic repositories where papers published elsewhere are available in open access form.

Does anyone know the logic behind the version numbering? 4.0x's seem to have pretty major changes between them. And what's the leading zero?

Interesting. Not being that familiar with Nix(OS), how much of a moving target Nix is? Can you do these kinds of things with stable versions or do you need to keep up with HEAD?

With golang, it is incredibly easy to get productive fast. It's like modernized, safe C with good standard library and trivial deployment. Those are pretty good selling points for getting stuff actually done.

Using Haskell for similar stuff is more tedious, even if a actual coding is more fun. I can see (and sometimes feel myself) the cognitive dissonance here.

Now that the cat's out of the bag, could the esteemed hacker(s) just post the source code, so that we can see how it was implemented :) (j/k)

At the end of the article:

Our next post examines how much urine splashes back on you when you use a urinal.

The range of articles is... interesting.

I don't remember exactly how I got started, probably by trying to replicate what bigger kids were doing with "intros" and demos. I don't know what would nowadays be a simple enough starting point. But I remember William Stallings' and Andrew Tannebaum's books on operating systems and computer architecture in the university 20 years ago. I don't know if they have been updated, but they might be good starting point, if you need to start from the beginning.

On the other hand, if you know basics of how to CPU works, what stack is, know binary and hexadecimal, and some C, you might be able to just read Dennis' book, just ignore things you don't get at first, since many things get explained later in the book, after which you can re-read sections you didn't quite understand first.

I agree. What I meant was that the title "Reverse Engineering for Beginners" might imply that this material would guide the reader from the beginning. Having background in 6502 assembly (thank you, Vic-20!) I didn't have that much trouble in following the presentation in the book. But if coming from higher level programming background and not having basic grasp of how CPUs work, following the text might be difficult.

This site and accompanying book (http://beginners.re/Reverse_Engineering_for_Beginners-en.pdf) seem a nice effort. Briefly reading the book, it seems that you need to be an intermediate or advanced beginner, or know something about assembly beforehand.

Some terms (opcode, ISA) are not really explained (except in the glossary) before they are used and there are perhaps too much detail in the expense of the bigger picture.

Criticisms aside, the book and the challenges seem interesting and the efforts of the author must be appreciated!

Yeah. Sadly, plain text email seems to be endangered species. But perhaps there is still hope, markdown and pals have made some inroads as all around useful document formats.

What are the main gripes against Docker? Security is one that I hear a lot, but is a bunch of Docker containers somehow inherently more insecure than running the same apps on the same host?

Docker seems to be moving forward really fast and gets a lot of hype which tend to make my old-school sysadmin self a bit suspicious, but I'd love to hear critique that is based on the actual usage. (N.B. I'm just about to start making my first Docker deployment)

I'm not sure if SML can catch up with OCaml's nice tooling (opam, merlin, Core, etc...), even if it feels a bit cleaner language to me. A Shame, but merits of a programming language are not proportional to its success.

Edit. Oh, and here's a previous discussion: https://news.ycombinator.com/item?id=2433860

Has the battle against HTML emails been lost?