• 1 Post
  • 220 Comments
Joined 3 年前
cake
Cake day: 2023年6月12日

help-circle
  • Are the talks not recorded for this year? They traditionally have been. There have been years where it was streamed too. Can’t remember for 2026.

    There are few places I know of where I’ll find people running Linux on their phone or on their Mac too. You’ll surely find people running some BSD, MacOS, Windows or whatnot as well as those running Linux on their laptops.

    FOSDEM has had the highest amount of FOSS OS use and rooted devices over any conference I’ve been to.

    You’ll surely find vibe coders or people using LLMs as is the case everywhere today. You’ll also find people deep into the field talking about shaving bytes off a Python interpreter to fit it on a small chip or talking about high level database abstractions or the bluetooth stack in the Linux kernel because they implemented part of it. But sure, it’s huge. You’ll find others too. Some will learn, some will leave.

    It is not perfect but there’s substantially worse places to be to learn about FOSS subcommunities.




  • Disclaimer: I stopped reading at 3/4 of the article and started scanning because it looks like lack of familiarity looking for a scientific explanation. Then scanned parts again for a lengthy response to clear my thoughts. That may be wrong and I’ve heard the complaints but my experience is different. Much of why it doesn’t resonate is looking at it from a different perspective by different experience.

    I mostly write javascript and some lisp and a smaller portion of python, ruby and others. The lisp parens are substantially easier for me to scan than the Java syntax for everything except nested function calls which start with many open parens. Common Lisp doesn’t do that often so it is new to me like the Java syntax was new to me back in the day. Good as an abstraction if that’s what you get to work with.

    I would love for my experience to be different because then I’d enjoy Java.more(with,all){ the(); weird(); return symbols();}. But I do not. Lisp groups things starting with an opening paren up to the closing paren. No scanning for the type of grouping like (, {, or [. Simple and consistent. Indentation is done automatically based on the meaning of the code and parens do the logical grouping (it works just like it works in sentences (but deeply nested parens are weird (like deeply nested routines (and we should limit that)))). There are places where it’s nice to escape from parens and Common Lisp allows for that so you can create a mini language without the parens (other lisps allow for that too). It is not created often but there are cases where that helps a lot.

    Both java and lisp wordings have their pros and cons. Deeply nested function calls are often solved with a macro to flatten that in Lisp. You don’t have that syntax flexibility as easy in Java but you can make other abstractions to lower the pain. In the end it’s finding the right vocabulary and structure to explain the problem and the solution. Each language has its own tools for that. Lisp has less familiar tools but you can do more with them. Once you know it’s hard to settle for less but if you don’t it’s hard to see what you’re getting bound by. In the same way lispers don’t always see the many libraries available in python, pythonistas don’t see the limitations the language itself imposes on them.

    The article, to me, thus reads as the statement “parens feel hard to read to me” searching for a reason other than “I have not seen it as often”. I have seen far more C-like syntax than Lisp but I’ve seen a good share of lisp too. Structure is more apparant to me in Lisp like languages. It is cleaner for words to be split by spaces than,for,them,to,be,split,by,commas in an argument list.

    In my opinion, Lisps are hard to read because they use eq and eql and equal instead of === and ==; and setq and setf and let instead of =; and car and cdr instead of first and rest. Historic wording. Also in elisp I find it hard to find the right function name. Yet in our configuration DSL most non lispers choose the Lisp syntax over JSON but they only liked it after the JSON syntax became an option too. Until then they wanted JSON.

    I have noticed a difference in reasoning about code. A lot of Lisp code reads like an outline where you zoom in to the relevant spot. A lot of Java and Javascript reads like a series of commands you execute in your head sequentially. The languages lend themselves to such code even though they support both ways of writing. Perhaps that difference was not experienced by the author?

    This comment is really just another person’s experience but it’s a different experience that what’s projected in the article.

    To come to the conclusions from the article:

    • Claim: “prefix notation puts parentheses further apart”
    • Reply: The parens fill space and the whitespace shows what belongs together, it is the closest consistent grouping and allows arguments to be read by space separated words rather than hard to read commas or by newlines if that helps scanning the code. In case the arguments (or a subset of them) warrant specific grouping, lisps offers support for that in a mkre integrated manner than Java does.
    • Claim: “formatting practices do not help to track parentheses”
    • Reply: use a formatter, it does that. Lisp code reads like a nested structure you walk rather than a piece of code you mentally execute line by line. We don’t format whitespace at the start of the line in Java either, right?
    • Claim: prefix notation results in more left-nesting
    • Reply: use a macro, currying, or any other macro structure when it helps. Turn the language into whatever you need to express the solution. If I have too many parens I rewrite the code just like you’d do in amy other language. Executing Food.buy().bake().serve().eat() is a cool Java DSL and reads nicer when written in lisp as (-> Food buy bake serve eat) anyways so why write (eat (serve (bake (buy food)))) if your focus is not eat. Though if it is eat then do write that. Or perhaps write it in the other direction with compose. So many options if that’s the sort of code to write.
    • Claim: Lisps lacks or discourages features that align the evaluation and reading order
    • Reply: I agree and it’s good. Other programming languages focus on the execution of commands following one another. Lisp encourages a functional programming style where the structure makes meaning easier to navigate through the code. Both are possible in a variety of languages. That’s a choice though, not a problem. It is trivial to use abstractions that neatly express such an order even when the code around it is not made for it (with-food-plan (buy) (bake :lightly) (serve :hot) (eat)) and the function calls will be nicely indented on newlines by your editor if that’s the best use of the space.

    On the advice:

    • advice: “order notation such that related tokens (e.g., delimiters) are as close as possible”
    • reply: Lisp has that and more than other languages. You can make up your own syntax when the problem warrants it. For example the loop DSL for looping over lists. It’s just not always the best to read.
    • advice: “use the shape of code to communicate grouping”
    • reply: yes. The opening paren starts the group, the closing ends the group. The meaning of a group is fluid but consistent. Use newlines and auto-formatting for easy vertical scanning of lisp code.
    • advice: use associativity to prevent nesting delimiters
    • reply: not sure but I think the answer are DSLs or macros when things get too bad. But sure, readable code is nice. Context switches are hard.
    • advice: design syntax and semantics to align reading with evaluation order
    • reply: I disagree here but it’s the difference of functional versus procedural thinking. Code needs to explain itself. The order of evaluation is what a computer needs, I need an order of understanding. If I can have my way I’ll optimize the code to have the main structure and reasoning up front and the details and exceptions at the bottom. I don’t care about negative numbers being a special case early on through an early return, I want the know what the general algorthm is first. Some disagree. Evaluation order is super important for computers but I don’t care how my SQL query is executed, I care to understand it and for it to be fast enough. Otherwise I’d use a different technogy.

    Not mentioned in these are symbols such as a < b versus (< a b). I like the former better. But a < b < c has more room for interoretation than (< a b c) for me. An infix macro can easily solve the problem to read as (. a < b) and we can go further too.

    So, much of this is probably written with the best intentions and a real experience. I can see it being true for their point of view with their history. This is also just a quick thought and response tk put things in persoective for me. A response through a different lens with a different experience.




  • I do not know the details of this story but they have indicated that they can not be competitive with Chinese imports based on current safety and human standards and costs (for electric trucks). Unions and good working conditions are expensive. Western manufacturers have an advantage in combustion engine and drivetrain expertise.

    I doubt they want to destroy the world. They certainly want to continue running a profit. Competition lowers profits. But being really incompetitive means losing the market. Losing thr market means no trucks built by our human standards.

    We should require imports to at least have been built on the same standards as hold in our market. We should speed up ecological efforts and demand good worker conditions, safety standards and ecological standards from every product that reaches our market.


  • The internet is great for connecting machines. HTTP(s) could even be used to transfer messages. Blockchain is good for maintaining a historical record. The farther down the chain you go, the harder it becomes to rewrite history. You pay for this feature by requiring everyone to permanently keep the whole shared historical record. Some workarounds for the permanent storage of the whole history exist but that’s blockchain in a basic form. The permanent record is a nice feature for things like financial transactions.

    Blockchain bros tried to convince us blockchain is great for sharing information in an effort to increase its relevance. You may connect it for that reason. In their defence, blockchain can be used for data transfer, it’s just not that great at it.

    Blockchain could be used to assert trust, but most problems have equally good or better alternative solutions for that. Very often these use digital signatures and public-private keypairs.

    You may want to look at YaCy for a decentralised search engine.



  • Not saying you should buy new, but compare prices with Starlabs and Slimbook etc too when you’re at it. System76 and certainly frame.work are more on the expensive side. Slimbook has had a good spare parts catalog for my model, no idea about others. Maybe wait for a Canada-EU trade deal XD

    I don’t study the market but I’m not counting on price drops in the coming 2 years. Real cost will likely go down only with inflation.


  • There are cases where it is actually necessary. An example would be to download personal documents from a government website. A proof of good behaviour would be one of those. Opening a bank account online is another one with current legislation.

    I think it could go further, but this seems to be a well balanced step in the right direction. It is achievable. We can build from there if more os needed.

    The text is short and many will not read the full content. More detail would be nice. This is great as a start for debate so the initiative would be a net positive. Get people on the band wagon and see who sticks around for another round.





  • I love the argument you make here. I disagree, but it’s a direct, hard and positive set of statements.

    Nuclear takes a decade to build, it concentrates power to a large actor, and we have issues with handling waste (including closing down the plantO. The risks are huge when in a war zone (see Ukraine) and when things go bad they go bad for many. Further, nuclear can’t rapidly scale up or down so it’s not great at handling fluctuations in demand, similar but less extreme than wind and solar without batteries.

    Progress has been made. With each step we think it’s now really safe. But a few decades later it turns out we still had a bit more to learn. In the seventies they were telling us it was safe too.

    Ever since there was a glimmer of hope that costly reactors could get built again there has been a weird amount of positive posts about how great nuclear is. I don’t think we know how to store anything for 1000 years because we have not had the necessary structures in place for so long yet and thus we are de facto finding that out.

    Batteries are not cheap. But solar and wind are! I think, based on what I’ve read, that that is a great path forward. It is safe, and it puts power in the hands of the people. No need to buy uranium from the next slowly corrupting regime. No need to get threatened by a company that they’ll ahut the plant down. You have read other things and believe nuclear is the right way. No CO2, safe, good power delivery, limited space use. Neither of us is calling the shots on these decisions.

    I guess one will clearly be better than the other based on geography and available workforce.

    If we can continue to choose the least impactful and most distributed and cheapest long-term (including plant cleanup, windmill recycling, solar panel recycling, nuclear waste storage, battery recycling) then we’re on a good path. I hope we can do that whilst subsidizing research on all these fronts.


  • The way I’ve used it is more that the text gives an explanation and a structure regardless of what the framework requires. It’s not the exact algorithm per se but it could if it’d ver very complex for some reason. It ends up reading like a book with code snippets in it which turns out to run the application.

    I also generally edited the code directly and indirectly and then detangled or tangled such that the files were in sync.


  • I agree with that to some extent. It was probably not the engineers’ task, but as I’ve read in the past, our models of the seventies were not that far off. They did not plan for it probably because they were asked not to, or perhaps they (like many others) did not want to believe in the doomsday predictions, or perhaps they (like many others) believed it would be solved by science by now. The warnings were there though, we chose to ignore what was coming at us if we did not change our ways.

    My point is that by stating the reactor could work, you imply that there’s a trivial solution: stop protecting nature to have nuclear electric energy in France. You could state explicitly that we should or should not. By leaving it open it feels to me like we’re pretending nuclear is ready for the climate change ahead of us if only we could get way with that stupid nature. An argument could be had I suppose.

    As a side-note: It did make me wonder if you could work with complete evaporation. Not dumping any water back. That would also be horrible for nature but I don’t know if anything in the system has to run at less than 100C.


  • To my knowledge, but I did not look this up, these constraints were known at design time. I don’t recall these changing. Hence the statement may be true, but pointing at the known constraint after the fact shifts the blame to nature conservation rather than infrastructure and climate change. This at a time where climate change focus is of utmost importance.

    Hence, albeit factually correct, it is disingenuous to give it the focus.

    If these constraints were added in the past 10 years then that could be considered different depending on the reasons for the change.

    What has changed are the water levels and base temperatures. Our environment has changed and the infrastructure has not been adapted to it. Luckily we have other tools for generating electric power ready to be rolled out.