Lichess uses a scheme which is probably more efficient on average, described on revoof's blog[0]. Basically, it's a variable length scheme where the first 64 bits encode square occupancies, followed by piece codes (including castling, side to move, and ep with some trickery), followed by half-move clocks if necessary.
It also can encode chess960 positions. With the article's encoding, uncastled rooks can only be decoded if their starting position is known, which it isn't in chess960.
It’s mathematically dissatisfying, but often the most optimal storage (or algorithm) solutions involve clever heuristics that are dynamically applied.
Some systems just have to be observed in order for solutions to be optimally designed around how they actually behave, rather than how they theoretically behave.
For about two and a half years I worked on a Smalltalk system, written in a quite old Smalltalk, which gave me two idiosyncrasies editor-wise: I no longer care very much about syntax highlighting (though I don't really bother to turn it off), and I now prefer to use proportional fonts for my programming. The only syntax highlighting I missed in the Smalltalk was a fading out of comments (which would in fact have prevented a stupid issue similar to the comment thing shown in the OP).
Good PBT code doesn't simply generate values at random, they skew the distributions so that known problematic values are more likely to appear. In JS "__proto__" is a good candidate for strings as shown here, for floating point numbers you'll probably want skew towards generating stuff like infinities, nans, denormals, negative zero and so on. It'll depend on your exact domain.
I'm pretty sure the publishers are alleging that a crime has been committed. In that case, private parties can't open a suit (at least if Swedish criminal law is at all similar to Norwegian law), so this asks the police to open a criminal investigation into the matter. What happens next in the Norwegian system at least is that the police will conduct their investigation, and at some point when the police consider their investigations complete the prosecutor's office will decide what to do next. Next steps can be concluding that no crime has occured, to ask the police to investigate further, that a crime has been committed but the evidence are insufficient for a trial, or that someone should be tried.
Surely you can still sue separately through the civil process even if you choose to not pursue criminal charges?
If someone causes you damage through non-criminal negligence, surely you can sue them?
The idea that you couldn’t bring a civil suit over possibly criminal conduct seems unworkable. It’s possible that my neighbour was drunk when he crashed into my parked car late at night, but surely that can’t preclude me from seeking compensation through civilian courts.
It’s possible, but tremendously unlikely that Facebook is committing fraud here. In Sweden you have to prove intent to defraud, which is a tremendously high bar.
Which, again, makes the idea that you couldn’t bring a civil suit seem ever more bizarre. How could you possibly know if Facebook has committed fraud here? You presumably can’t read Zuckerbergs toughts.
In that particular example (drunk neighbour damaging your property with reckless driving) is really — in most of Europe, I would guess as Serbian laws are largely copied over from different EU country laws — handled by the insurance.
Basically, insurance against damage to others is obligatory for anyone to get the car registered and on the road.
If someone drives an unregistered, uninsured vehicle, a consortium of all insurance companies pay for the damage, and sue the perpetrator in a civil case.
In general, you can argue your level of damage with the insurance company, and can even take them to court.
In Serbia, drunk driving actually precludes the liability of the insurance company too, but they still need to pay out the damages first, and bring a civil case against the driver to get compensated. For that, they need a criminal conviction.
(I've had the unfortune to be hit by a drunk driver, luckily no other harm than to the property as both cars have been totalled, and his insurance argued a lower value for my almost new car)
I am guessing here the "intent" can also be "aware of it but did not invest enough to curb it while it is profiting off it".
Yeah, I know how car insurance works and just figured it’d be overly verbose to specify some scenario where the neighbour was driving some uninsured vehicle like a tractor and the incident happened outside of public roads.
I do think I still managed to make my point though, preventing civil lawsuits arising from possibly criminal behaviour is unrealistic. That would make it extremely difficult for individuals to seek compensation for almost any damage they might suffer, they’d have to first wait for months or years before the police gets back to them.
>I am guessing here the "intent" can also be "aware of it but did not invest enough to curb it while it is profiting off it".
Fraud by negligence is a fairly exotic concept and to my understanding usually specifically relies on laws regarding negligent misrepresentation. I’d be surprised if that would work in Sweden.
>For liability for fraud to come into question, the prosecutor has to be
able to prove that the crime is deliberate. This means that the criminal
act has been committed consciously or intentionally. Liability for fraud
is conditional on the objective requisites being covered by the perpetrator’s intent. It is not possible to judge a person to be liable for fraud because someone has been paid too much compensation as a result of negligence, or because the person did not know about certain obligations in
conjunction with the compensation. Carelessness is thus not sufficient.
It must be possible to prove that the perpetrator has committed the act
intentionally. This intent must cover all elements of the criminal act.
The great problem with fraud crime is to prove the intent. The actual
circumstances surrounding what really occurred are often a lesser pro-
blem. The assessment of the intent is complicated by the fact that the
rules concerning social insurance can be difficult to understand.
The difficulty in proving intent has meant that several assessors have
considered that the fraud regulations do not work quite as they should.
Proposals have therefore been made that negligence should be sufficient
for judging that a person has misled the Social Insurance Agency or
some other payment-issuer within the compensation and benefit systems
(Örnemark Hansen, 1995). This criticism against the intention require-
ment has led to the new Benefit Crime Act (2007:612).
Generally legal system has negligence, and once someone is provably informed of the negative consequences but keeps being negligent, "willful negligence", which is much closer to intent (I see it defined as "intentional disregard...").
IANAL, but common sense tells me there should be a link to willful harm.
I found the Smalltalk way of working in the running environment to be very programmer efficient too, and that it was by far the smoothest development experience I’ve had, even in a pretty dated and clunky Smalltalk at that point. And debugging wasn’t really a problem in my experience, but we stored application state outside of the image in an SQL database (initially Sybase, then MSSQL), which probably removes some «haha, the image has some weird data saved in the dark and dusty corners» issues.
I worked on a Smalltalk system which ran on Visual Smalltalk Enterprise, and in that system the image opened its windows as native Windows GDI windows, which made the application quite seamless in the OS (except this was in 2016-2018 and VSE was last updated in ‘99, so the look and feel was a bit dated :D).
I've only used PBT a few times, but when it fits it's been extremely useful. A concrete example from my practice of what has been pointed out in this thread, that you want to properties of your function's output rather than the output itself: I was implementing a fairly involved algorithm (the Zhang-Shasha edit distance algorithm for ordered trees), and PBT was extremely useful in weeding out bugs. What I did was writing a function that generated random tree structures in the form I needed for my code, and tested the four properties that all distance functions should have:
1. d(x, x) = 0 for all x
2. d(x, y) >= 0 for all x, y
3. d(x, y) = d(y, x) for all x, y
4. d(x, z) <= d(x, y) + d(y, z) for all x, y, z (the triangle inequality)
Especially the triangle inequality check weeded out some tricky corner cases I probably wouldn't have figured out on my own. Some will object that you're not guaranteed to find bugs with this kind of random-generation strategy, but if you blast through a few thousand cases every time you run your test suite, and the odd overnight run testing a few million, you quickly get fairly confident that the properties you test actually hold. Of course any counterexamples the PBT finds should get lifted to regression tests in addition, to make sure they're always caught if they crop up again. And as with any testing approach, there are no guarantees, but it adds a nice layer of defense in depth IMO.
In discussions like this, I sometimes feel that the importance of related work like the increasing use of Rust in Android and MS land is under-appreciated. Those who think C is fine often (it seems to me) make arguments along the lines that C just needs to have a less UB-prone variant along the lines of John Regehr and colleagues' "Friendly C" proposal,[0] which unfortunately Regehr about a year and a half later concluded couldn't really be landed by a consensus approach.[1] But he does suggest a way forwards: "an influential group such as the Android team could create a friendly C dialect and use it to build the C code (or at least the security-sensitive C code) in their project", which is what I would argue is happening; it's just that rather than nailing down a better C, several important efforts are all deciding that Rust is the way forward.
The avalanche has already started. It is too late for the pebbles to vote.
> This post is a long-winded way of saying that I lost faith in my ability to push the work forward.
The gem of despair:
> Another example is what should be done when a 32-bit integer is shifted by 32 places (this is undefined behavior in C and C++). Stephen Canon pointed out on twitter that there are many programs typically compiled for ARM that would fail if this produced something besides 0, and there are also many programs typically compiled for x86 that would fail when this evaluates to something other than the original value.
Some parts of the industry with a lot of money and influence decided this is the way forward. IMHO Rust has the same issue as C++: it is too complex and a memory safe C would be far more useful. It is sad that not more resources are invested into this.
I'm entirely unconvinced that a low-level† memory safe C that is meaningfully simpler than rust is even possible, let alone desirable. IMHO Basically all of rust's complexity comes from implementing the structure necessary to make it memory safe without making it too difficult to use††.
Even if it is though, we don't have it. It seems like linux should go with the solution we have in hand and can see works, not a solution that hasn't been developed or proved possible and practical.
Nor is memory safety the only thing rust brings to the table, it's also brings a more expressive type system that prevents other mistakes (just not as categorically) and lets you program faster. Supposing we got this memory safe C that somehow avoided this complexity... I don't think I'd even want to use it over the more expressive memory safe language that also brings other benefits.
† A memory-safe managed C is possible of course (see https://fil-c.org/), but it seems unsuitable for a kernel.
†† There are some other alternatives to the choices rust made, but not meaningfully less complex. Separately you could ditch the complexity of async I guess, but you can also just use rust as if async didn't exist, it's a purely value added feature. There's likely one or two other similar examples though they don't immediately come to mind.
I don't think so. First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C. Second, I do not even believe that memory safety is that important that this trumps other considerations, e.g. the complexity of having two languages in the kernel (even if you ignore the complexity of Rust). Now, it is not my decision but Google's and other company's influence. But I still think it is a mistake and highlights more the influence of certain tech companies on open source than anything else.
> First, Rust did not come from nowhere, there were memory safe C variants before it that stayed closer to C.
Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use?
> Second, I do not even believe that memory safety is that important that this trumps other considerations
In your previous comment you stated "a memory safe C would be far more useful. It is sad that not more resources are invested into this". It seems to me that after suggesting that people should stop working on what they are working on and work on memory safe C instead you ought to be prepared to defend the concept of a memory safe C. Not to simply back away from memory safety being a useful concept in the first place.
I'm not particularly interested in debating the merits of memory safety with you, I entered this discussion upon the assumption that you had conceded them.
> Can you give an example? One that remained a low level language, and remained ergonomic enough for practical use?
They can't, of course, because there was no such language. Some people for whatever reason struggle to acknowledge that (1) Rust was not just the synthesis of existing ideas (the borrow checker was novel, and aspects of its thread safety story like Send and Sync were also AFAIK not found in the literature), and (2) to the extent that it was the synthesis of existing ideas, a number of these were locked away in languages that were not even close to being ready for industry adoption. There was no other Rust alternative (that genuinely aimed to replace C++ for all use cases, not just supplement it) just on the horizon or something around the time of Rust 1.0's release. Pretty much all the oxygen in the room for developing such a language has gone to Rust for well over a decade now, and that's why it's in the Linux kernel and [insert your pet language here] is not.
BTW, this is also why people being are incentivized to figure out ways to solve complex cases like Rcu-projection through extensible mechanisms (like the generic field projection proposal) rather than ditching Rust as a language because it can't currently handle these ergonomically. The lack of alternatives to Rust is a big driving factor for people to find these abstractions. Conversely, having the weight of the Linux kernel behind these feature requests (instead of e.g. some random hobbyist) makes it far more likely for them to actually get into the language.
I don't think there are many new ideas in Rust that did not exist previously in other languages. Lifetimes, non-aliasing pointers etc all certainly existed before. Rust is also only somewhat ready for industry use because suddenly some companies poured a lot of money in it. But it seems kind of random why they picked Rust. I do not think there is anything which makes it particularly good and it certainly has issues.
"Lifetimes" didn't exist before. Region typing did, but it was not accompanied by a system like Rust's borrow checker, which is essential for actually creating a usable language. And we simply did not have the tooling required (e.g. step-indexed concurrent separation logic with higher order predicates) to prove a type system like that correct until around when Rust was released, either. Saying that this was a solved problem because Cyclone had region typing or because of MLKit, or people knew how to do ergonomic uniqueness types because of e.g. Clean, is the sort of disingenuous revisionist history I'm pushing back on.
> But it seems kind of random why they picked Rust. I do not think there is anything which makes it particularly good and it certainly has issues.
Like I said, they picked Rust because there was literally no other suitable language. You're avoiding actually naming one because you know this is true. Even among academic languages very few targeted being able to replace C++ everywhere directly as the language was deemed unsuitable for verification due to its complexity. People were much more focused on the idea of providing end to end verified proofs that C code matched its specification, but that is not a viable approach for a language intended to be used by regular industry programmers. Plenty of other research languages wanted to compete with C++ in specific domains where the problem fit a shape that made the safety problem more tractable, but they were not true general purpose languages and it was not clear how to extend them to become such (or whether the language designers even wanted to). Other languages might have thought they were targeting the C++ domain but made far too many performance sacrifices to be suitable candidates, or gave up on safety where the problem get hard (how many "full memory safety" solutions completely give up on data races for example? More than a few).
As a "C++ guy" Rust was the very first language that gave us what we actually wanted out of a language (zero performance compromises) while adding something meaningful that we couldn't do without it (full memory safety). Even where it fell short on performance or safety, the difference with other languages was that nobody said "well, you shouldn't care about that anyway because it's not that big a deal on modern CPUs" or "well, that's a stupid thing for a user to do, who cares about making that case safe?" The language designers genuinely wanted to see how far we cold push things without compromises (and still do). The work to allow even complex Linux kernel concurrent patterns (like RCU or sequence locking) to be exposed through safe APIs, without explicitly hardcoding the safety proofs for the difficult parts into the language, is just an extension of the attitude that's been there since the beginning.
Rust isn't perfect, but it's basically the most viable language currently to be used in software such as Linux. It's definitely more of a C++ contender than anything else, but manages to be very usable in most other cases too. Rust 1.0 got a lot of things right with its compile-time features, and the utility of these features for "low-level" code has been demonstrated repeatedly. If a language is to replace Rust in the future, I expect it will take on many of the strengths of Rust. Moreover, Rust is impressive at becoming better. The work for Rust-for-Linux, alongside various other improvements (e.g. next trait solver, Polonius and place-based borrowing, parallel rustc frontend) show that Rust can evolve significantly without a huge addition in complexity. Actually, most changes should reduce its complexity. Yes, Rust has fumbled some areas, such as the async ecosystem, the macro ecosystem, and pointer-width integers, but its mistakes are also considered for improvement. The only unfortunate thing is the lack of manpower to drive some of these improvements, but I'm in it for the long run. Frankly, I'd say that if the industry had to use only one language tomorrow, Rust is the best extant choice. Really, I'm open to
And, it's really funny that GP criticizes Rust but doesn't acknowledge that of course blood, sweat, and tears have already gone into less drastic variants for C or C++. Rust itself is one of the outputs of the solution space! Sure, hype is always a thing, but Rust has quite demonstrated its utility in the free market of programming languages. If Rust was not as promising as it is, I don't see why all of these companies and Linus Torvalds would seriously consider it after all these years of experience. I can accept if C had a valid "worse is better" merit to it. I think C++, if anything, has the worst value-to-hype ratio of any programming language. But Rust has never been a one-trick pony for memory safety, or a bag of old tricks. Like any good language, it offers its own way of doing things, and for many people, its way is a net improvement.
For example cyclone, checked C, safe-c, deputy etc.
I agree that memory safety is useful, but I think the bigger problem is complexity, and Rust goes in the wrong direction. I also think that any investment into safety features - even if not achieving perfect safety - in C tooling would have much higher return of investment and bigger impact on the open-source ecosystem.
After a couple of years working in Smalltalk, I’ve acquired the hot take that all the code should be in a proportional font. Admittedly it doesn’t work quite as well for brace syntax languages, but in Smalltalk and Python it’s great.
KT is obviously (from context here) Karahan Tepe, and GT thus Göbleki Tepe. ANE is a standard abbreviation for Ancient Near East. For PPNA Wikipeda supplies Pre-Pottery Neolithic A, which is a subdivision of the Early Neolithic period.
0: https://lichess.org/@/revoof/blog/adapting-nnue-pytorchs-bin...
reply