EdiX

Underrated comment.

I speak three languages and I'm learning a fourth. Don't study grammar, ever, it's a waste of time. Grammar rules always fall into one of two categories: the ones that are so obvious that you would have learned them after two examples anyway or the ones that are too vague and complicated to be useful. For an example of the latter look up people making flowcharts for the subjunctive or for the ga/wa distinction. Or, for that matter, find me the place in an english grammar that explains why you get "on" a train, but "in" a car.

US households constitute 21% of all energy use [1], so 22% of this is 0.21 * 0.22, which is 4%.

[1] https://rpsc.energy.gov/energy-data-facts

I don't disagree, but you're just explaining why it doesn't work.

> It's a commonplace of international relations, and intuitively obvious, that the more integrated are the economies of two countries, the less likely they are to start wars with each other

This is indeed a common way of thinking and intuitively obvious but I think it has also been proven wrong by the war in Ukraine. We sanctioned Russia as hard as we could and it 3 years later they're still there.

Withholding some nebulous service industry from a country that's mostly reliant on primary and/or manufacturing is probably not a strong enough deterrent to a sufficiently motivated political force. It might be that it just puts service industry reliant countries at a disadvantage.

Drone warfare is another piece of the puzzle, both how they are employed in the Ukrainian war as well as in the red sea blockade. The west is also at a disadvantage here compared to, say, China. When was the last time you saw a drone-dragon lightshow outside of Shenzhen?

We thought we had world peace through commerce but it was probably an illusion. I think everyone is rethinking the last 150 years of history right now.

How is this not justified? For that matter, how was rachelbythebay's first post not fingerpointing? "You might not want to be associated with nukem222, not even a little bit, if you know what I mean".

I gave her the benefit of the doubt initially, she usually posts good posts, but this is not the way to do things. Vagueposting about a security vulnerability without properly disclosing it to the mantainers: (1) damages their reputation, (2) sends every blackhat on the hunt like a real life worldwide CTF event, (3) leaves sysadmins in the dark unless they are following this specific random blog and (4) since the details aren't known even if they know it's impossible to determine if they really are affected.

Something like this would be justified if the maintainers were unresponsive and it was a remotely exploitable bug. Now it turns out this is probably a minor thing (local privilege escalation if you happen to be running atop as a privileged user).

It seems to me like an irresponsible, egocentric way to handle things.

If search engines were invented today they wouldn't stand a chance. People would complain that they can return immoral results. Different sets of people would complain that they can return links to various isms that offend them. The owners would be worried that they return results critical of themselves or their friends. Copyright owners would sue them for linking to piracy. Website owners would block them for reading their precious content.

> Or the lie about funding an opera about a transgender woman (the money was for a university in Columbia, unrelated to a performance put on at the school).

You've got that wrong. The grant to fund the opera exists: https://www.usaspending.gov/award/ASST_NON_SCO20021GR3086_19.... Specifically the grant was given "to raise awareness and increase the transgender representation through the opera As One, by American composer Laura Kaminsky".

The lie in this case would be that USAID awarded the grant, it was awarded by the Department of State instead.

> The government is paying claims for people who are 150 years old.

This more likely than you think, likely enough, in fact, that it has already been confirmed to have happened in multiple countries [1]. The problem of fraud and data corruption is widespread enough that it is hampering longevity research [2][3]

    [1] https://www.cremieux.xyz/p/the-blue-zone-distraction
    [2] https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.3000148
    [3] https://www.biorxiv.org/content/10.1101/704080v3

This isn't really new, there have been projects like this since forever. Microsoft used to ship one with Office, even. I wish they had published something about why they stopped doing it, maybe that would prevent people from repeating the same mistakes. I was subjected to one of those translated programming languages 20+ years ago: they are traps two weeks in you realize you can't do anything without either learning a different programming language (with english keywords) and reaching for external libraries that will define english identifiers and often even have english documentation. I wish I could get back every minute I spent with it and could reinvest it into learning english.

My understanding is that FOSDEM is run by volunteers on a shoestring budget mainly thanks to the support of the ULB (a university). They don't have security, they don't have badges or registrations, you can just walk in and out as you please. I have my doubts this is going to last if people start to deliberately try to take a fat dump on it to elevate their own ego.

For Go there's a program called rf (https://pkg.go.dev/rsc.io/rf) that's along those lines. It isn't worked on as much as I wish it was.

Those are all orthogonal concerns to the way the text editor behaves. You could have a structural text editor operate on plain text files and a dumb text editor operate on AST, you can do plain text diffs of ASTs or diff AST parsed from plain text files, etc etc...

Some of these have existed historically (or even still exist).

Paredit-mode is a structural text editor that saves and loads plain text files, Smalltalk was typically implemented as a dumb text editor but then code was saved as compiled binaries (which meant you couldn't save your functions if they weren't syntactically correct but you could have unsaved syntactically broken functions), Mathematica represents its code in a weird format that might as well be binary but copy/paste converts to plain text, there's one git plugin (don't remember the name right now) that does syntax aware diffs even though git deals with plain text...

I used a structural text editor a while back (technically a structural text editing mode for emacs). I went in completely buying the structural text editing propaganda (it's more logical, it will make you more efficient, it's the future...) but I eventually found the experience so excruciatingly bad and stupid that I now think the whole endeavour is a complete waste of time, the idea sounds good on paper but there are some fundamental unsolvable problems with it.

The problem is that, when you want to make a change to piece of source code you know its current state and you know how you want it to look like at the end. With a normal text editor you will simply make a bunch of changes that turn the text as it into what it should be, it will normally go through a series of invalid states but you don't have to think about what those states will be or care about them. With a structural text editor this is impossible, invalid states can not be represented so when you want to make a change to your source code you don't just care about the beginning and end state, you also want to find a series of valid states that takes you from the beginning to the end where each one can be reached from the previous one with an editor command.

For example, let's say you have a function call:

    (afunc 1 2 3)

and you want to turn it into a conditional function call based on a flag:

    (if flag (afunc 1 2 3))

with a normal text editor you:

    1. type "(if flag " before the call
    2. type ")" after the call

It doesn't matter the order in which I do these operations or how I move the cursor.

With a structural text editor, I have to:

    1. create a new form before the function
    2. type "if flag"
    3. select the entire function call
    4. cut it
    5. paste it as the first branch of the if

This is however only possible if the context where the function call currently is allows adding a new node before it (i.e. it's inside the equivalent of a lisp progn). If not I'd have to use a different strategy, for example:

    1. select the entire function call
    2. use a command to create a node around it
    3. type "if flag"

I did this for a few months, eventually I realized that I didn't want to think about the syntactical validity of the intermediate states my program goes through while I'm editing it, because they exist for mere seconds, and I didn't want to memorize the large palette of commands necessary to create those intermediate states. It was all additional cognitive load that accomplished nothing but satisfy someone's esthetic sense that source code should always be in a syntactically valid state.

So of the benefits listed in the article:

1. "No syntax errors" is actually a major detriment of the structural editing model

2. "Better type information" is a lie, all that the structural text editor guarantees you is that the program is syntactically valid, not that it will pass type checking

3. "No keywords" is a lie, it's only true if you use a new programming language and don't store it on disk as text which opens a whole other can of worms (can't even read source code without a special text editor, won't work with github, won't work with any versioning system, won't work with grep, can't copy paste a chunk of it in an email...)

4. "Rich visualization" is an entirely different story from structural text editing but as far as I know nobody has ever shown visual programming to actually provide any kind of tangible benefit

5. "Reduced complexity" is the one I give them, yes if you are making a structured text editor you don't have to write a fault tolerant parser, it does make your (aka the text editor's implementor) life easier

Fans of structural text editors usually mention that they will unlock "more powerful refactoring tools" but actually all you need for those to be "unlocked" is a dumb parser and an automatic code formatter, like "go fmt". Refactoring a function to be inlined into another is still a difficult operation to implement correctly but it isn't like the difficult part is running a parser on the source code, it's dealing with variable shadowing.

If New Zealand is a western country do you consider Canada to be the middle east?

[flagged]

> Is anime & JAV to blame here?

Yes, people are going to be interested in a culture based on its cultural exports and Japan punches way above its weight in terms of cultural exports. And it's not just anime and JAV, it's also literature and music. Having content that you want to consume will make it easier to get motivated and to stay motivated. On top of that intermediate and advanced language learning is, to a large extent, driven by media consumption so the availability of a large amount of interesting content simply makes Japanese easier to learn than many other languages.

This is also how nearly everyone learns English.

When China will start exporting interesting content more people will want to learn Chinese and succeed in learning it.

There have been other murder/suicides of this kind (assuming that the theory is correct). Particularly SilkAir 185 and Germanwings 9525 (I think there is at least another one, but at the moment it is escaping me). In fact, my impression has been, for a long time, that MH370 is itself a copycat of SilkAir 185 where the suicide corrected the mistakes that led to the discovery that the accident was in fact caused by the captain.

I'm not particularly concerned about this, after the germanwings incident in europe and US (and possibly everywhere else as well) flight decks are required to always have at least two people: if one of the pilots wants or needs to leave one of the flight attendants must take his place.

You could do:

    func inspect(n ast.Node) func(func(ast.Node) bool) {
        return func(f func(ast.Node) bool) {
            ast.Inspect(n, f)
        }
    }

used:

    for n := range inspect(f) {
        fmt.Printf("%T\n", n)
    }

I've never used unison but I've used other, more traditional, REPL-based languages (think, Mathematica or Common Lisp with SLIME). To me one of the biggest problems with that style of programming is that sometimes code that you have changed on disk persists in the memory image, in the form of closures, creating unexplainable "ghost bugs" that disappear when you restart the REPL (or worse, that will only appear after you restart the REPL).

This system with making code immutable and storing it into a database makes me think somebody noticed how much of a footgun this behavior of REPLs is and thought... "mmmmhh what if we added a second barrel to the gun so that you can be sure to always shoot your own feet?"

The reason it's been stuck at version 11 is because X11 added an extension mechanism to the protocol and all improvements since have been added as extensions.

> These days, when you have a SAT-like problem, you're often done because you can throw a SAT solver at it, and it will give you an answer in a reasonable time

I don't know. All my experiences with SAT solvers have been bad. Sometimes adding constraints (and making the problem overconstrained) makes them orders of magnitude faster, sometimes it makes them orders of magnitude slower. Same goes for changing variables from integer to real or vice versa. And it varies from SAT solver to SAT solver, even on the same problem. I know enough about SAT solvers to know why this might happen but they're complete black boxes (as far as I can tell) and I can't predict their performance at all nor can I predict if a change I attempt will make them behave better or worse. I can't even tell if the bad performance is my fault or just the problem being legitimately to hard. And when it works I'm never sure if it will always work or if there are some inputs we have that will slip through the cracks of the heuristics it's using and hit us with a running time measured in days. If I could never use a SAT solver ever again I wouldn't.

Suppose you sell, or make, clothes. You don't want to sell a man's shirt to a woman or vice versa? With many designs it's obvious but for some it's close but you can't make that mistake so you need an easy, subtle way to distinguish them that won't impact form or function...

Even on X11 almost nothing sends server-side rendering command anymore. Almost every recent application (save for suckless stuff) renders cliends side, which means that if the x server is forwarded over the network every frame is a bitmap download. It's an extremely inefficient way of doing things and it should have improved upon but wayland choice to just discard this use case was, imo, extremely narrowminded.

> Why don't object files and binaries count as autogenerated artifacts? Should we commit those to the repo too? Where is the line between an artifact that should be committed, and one that shouldn't be?

I'd say anything that is input to the compiler should be.

> libc will dynamically load libnss-* on a lot of platforms, some of which can link to a bunch of other helper libraries. What if the attack had come via one of those 2-or-3-dependencies-removed libraries? libc is big and complicated and most programs only use a tiny fraction of it. Is libc a problem for the ecosystem?

Yes, the libnss stuff is also a problem.

> I would more just say autogenerated artifacts should just be autogenerated by the build.

There are practical and philosophical problems with this. From the practical point of view you generally want to make contributing (or even just building) your stuff as low friction as possible and having extra manual build steps (install tools X at version X1.X2.X3, Y at version Y1.Y2 and Z at version Z1.Z2rc2) isn't low friction.

Philosophically, you are just shifting the attack vector around, you now need to compromise one of tools X, Y and Z, which are probably less under your control than the artifacts they produce.

> And systemd has in fact deliberately made the notification process simple specifically so people can avoid the dependency

People say this but I'm skeptical, this is the actual documentation of the protocol:

"These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable. If the first character of $NOTIFY_SOCKET is "/" or "@", the string is understood as an AF_UNIX or Linux abstract namespace socket (respectively), and in both cases the datagram is accompanied by the process credentials of the sending service, using SCM_CREDENTIALS. If the string starts with "vsock:" then the string is understood as an AF_VSOCK address, which is useful for hypervisors/VMMs or other processes on the host to receive a notification when a virtual machine has finished booting. Note that in case the hypervisor does not support SOCK_DGRAM over AF_VSOCK, SOCK_SEQPACKET will be used instead. The address should be in the form: "vsock:CID:PORT". Note that unlike other uses of vsock, the CID is mandatory and cannot be "VMADDR_CID_ANY". Note that PID1 will send the VSOCK packets from a privileged port (i.e.: lower than 1024), as an attempt to address concerns that unprivileged processes in the guest might try to send malicious notifications to the host, driving it to make destructive decisions based on them."

So technically you have to support unix domain sockets, abstract namespace sockets, whatever SCM_CREDENTIALS is, whatever AF_VSOCK is and the SOCK_SEQPACKET note is completely obscure to me.

My personal takeaways from this:

1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar.

1a. As a consequence of (1) autogenerated artifacts should always be committed.

2. Autogenerated artifacts that everyone pagedowns over during code reviews is a problem. If you have this type of stuff in your repository also have an automatic test that checks that nobody tampered with it (it will also keep you from having stale autogenerated files in your repository).

3. A corollary of (1) and (2) is that autotools is bad and the autotools culture is bad.

4. Libsystemd is a problem for the ecosystem. People get dismissed as systemd haters for pointing this out but it's big, complicated, has a lot of dependencies and most programs use a tiny fraction of it. Encouraging every service to depend on it for initialization notifications is insane.

5. In general there's a culture that code reuse is always good, that depending on large libraries for small amounts of functionality is good. This is not true, dependencies are maintenance burden and a security risk, this needs to be weighted against the functionality they bring in.

6. Distro maintainers applying substantial patches to packages is a problem, it creates widely used de facto forks for libraries and applications that do not have real maintainers looking at them.

7. We need to make OSS work from the financial point of view for developers. Liblzma and xz-utils probably have tens of millions of install but a single maintainer with mental health problems.

8. This sucks to say, but code reviews and handing off maintainership, at the moment, need to take into account geopolitical considerations.

Ironically the Sagrada Familia is an example of modern architecture.

Nah, Google is just racist. Jack Krawczyk is on record making a bunch of racist remarks (against white people) and Youtube was sued multiple times for racial discrimination (against whites and males).

It just permeated the culture and produced a self censorship effect. Who's going to stand up, in a company they know to be racist, and flag racism in their product as an issue? Nobody.

And so even if anyone noticed the problem before release, they didn't report it.