1. 7

    The author seems to be very short sighted in my opinion. Even though I don’t like that cryptography library is moving to Rust, I’d rather they created a new crypto library in rust and donated the old C one to new maintainers. It is in the end their call, and Rust will provide a ton of safety features out-of-the-box.

    I think that it all boils down to which platforms the cryptography library committed to support. If they want to support all platforms that Python runs, then RIIR is the wrong option. If they’re going to make it clear that it supports just a subset of those, then it is quite OK. People who are in the orphaned platforms can fork the last known working version and move ahead with a new team.

    also SIGH but the first post linked on his sidebar is a rant where he explains why he refuses to wear a mask and calls business who force him to wear a mask, tyrants…

    1. 4

      Is your concern that they are keeping the “brand” for cryprography? There’s certainly nothing preventing new maintainers from taking over the C version…

      1. 1

        not the brand from a marketing perspective, but that build systems and other automated tools point-of-view. Those who are pulling their sources will depend on a whole new toolchain to build it, that affects package maintainers and products for a whole range of architectures.

        IMO, drastic changes like that should be done in new libraries so that it doesn’t break other systems. They could’ve declared that library finished, created cryptography2 or some other name and proceed to RIIR. The people using their library would have the option to stay with the unmaintained system and keep their stuff working, or go through the trouble of upgrading to the new library.

        1. 5

          They could’ve declared that library finished, created cryptography2 or some other name and proceed to RIIR

          That’s a strange inversion of responsibility. It’s also not viable since they’re doing an incremental rewrite, not a wholesale one. A wholesale rewrite might warrant a new library, but incremental rewrites are reliant on the full existing code and history to do properly.

          The responsibility for maintaining a library falls on the library maintainers. The responsibility for maintaining a distro falls on the distro maintainers. If a library stops supporting an environment, then the distro has to choose: also stop supporting the environment, or fork the library which they have license to do. “Tell the library maintainers to maintain their library differently” is not one of the options. Or, at least, not an option that will work.

          1. 5

            I personally would be okay with just a major version number bump or equivalent. Keep the brand, say the newer version is now the canonical one. Just:

            • keep the old one for a while;
            • mark the change as “breaking”.
        2. 2

          Rust will provide a ton of safety features out-of-the-box.

          Those safety features are almost irrelevant in the specific case of cryptographic code. Platform support aside, it won’t hurt, but it won’t do much good either. Don’t get me wrong, I would love that Rust be supported everywhere. Until then, C is still the better choice for portable cryptographic code.

          My biggest qualm about this change is that they didn’t mark it as “breaking change, let’s bump the major version number”.

          1. 5

            “My biggest qualm about this change is that they didn’t mark it as “breaking change, let’s bump the major version number”.”

            This was misunderstood by others as well. This project does not use semantic versioning, and the users were warned beforehand :

            https://cryptography.io/en/latest/api-stability.html#versioning

            https://github.com/pyca/cryptography/issues/5771#issuecomment-775038889

            https://github.com/pyca/cryptography/issues/5771#issuecomment-775041677

            1. 2

              They’ve changed their mind, and from now on their project will use a semver-compatible system. The version they released that caused the issues was on their old (weird) scheme, tho.

              1. 0

                Kudos to them, then. While ideally they should probably have reverted the change, switch to semver, then apply the change back, the switch to semver shows that they are listening to feedback.

          2. 0

            it’s significantly worse than that; see my other response here. this is simply a terrible person.

            1. 5

              Why don’t we stick to discussing the article, and leave the person out of it?

          1. 5

            oh my, I remember getting stuff from that collection from a local BBS using the fancy new ZMODEM which supported resumable transfers.

            1. 3

              I always thought KERMIT is underrated, and should have been much more popular.

              1. 3

                A lot of the ideas that Kermit implemented as a file transfer protocol where ahead of their time and a lot of similar features ended up in TCP. Kermit suffered in comparison to [XYZ]Modem because its default settings were tuned for really dirty lines. If you had the luxury of clean lines, [XYZ]Modem were clear wins due to their much larger buffer sizes and relative simplicity.

                1. 1

                  Safe defaults, but easy to make fast (Kermit FAQ has the settings). I still use it to transfer files back and forth with old PCs.

                  Also, sensible choice of CRC16 (CCITT variant, reflected for performance).

                2. 3

                  I only learned about the versatility of KERMIT way later in my life. ZModem was so convenient for large transfers on my time-limited session at the BBS. I kinda miss those days.

                  1. 2

                    I was lucky enough to attend a university with good network connections in the early 90s, and Zmodem was on its way out even then. Kermit was seen as old (but valued) tech.

                1. 2

                  I think that is my favourite FOSDEM talk ever. I’ve run many of the OSs listed there and went through a similar journey of discovering the road not taken. I too wonder what a new OS could be like. I knew I was in for a good talk when newtons and smalltalk appeared.

                  1. 1

                    Excellent! Thank you!

                  1. 2

                    FWIW, you can shorten the last 2 lines in mode() to the following idiom: return mode_map[m] or m.

                    1. 1

                      Heh, neat. Thanks.

                      1. 1

                        wow, that looks great. I’m surprised by how clean and straightforward it is.

                      1. 2

                        wow, went to check my site and found a single IP requesting my RSS every minute. That IP alone transferred 13GB of data since December. Damn. Thanks for raising awareness about such bad players @cadey.

                        1. 1

                          Good post, I learned a bit more about Lua.

                          @pushcx, consider folding this into https://lobste.rs/s/2lpxqj/lua_python

                          1. 2

                            Thanks for the kind words. That post was written as a reply to that Lua vs Python post, folding might be a good idea. I don’t know how folding works here to be honest.

                          1. 11

                            Thank you @soapdog, the HN thread also made me feel tired. Your post helped me remember there are others like me who do understand and appreciate the choices made by the authors of the language. And more people who understand that it’s not a zero-sum game, where one language being good (for some purposes) automatically means others must be “bad”.

                            1. 5

                              Thanks for the kind words. Someone posted that article on HN as a “real entry” instead of a comment reply like I did. Now, the amount of people devoting a ton of energy on 0-based indexes vs 1-based indexes, makes me tired. :-)

                              1. 0

                                Spite writes are the best writes!

                              1. 4

                                @soapdog: I think you linked to the wrong HN comment when talking about Janet? You linked to the parent of it?

                                I was the one who wrote that, my point wasn’t that Janet would replace Lua, but that for people that are looking for “Lua semantics, but with more baked in by default”, Janet may well end up filling that role for some.

                                1. 4

                                  @yumaikas, oops sorry. I will fix the link later. There is too much traffic right now and I use rsync to update the static files. I don’t want to touch the server right now. Sorry for the mistake.

                                  I like Janet a lot too, I even tried contributing some patches to make it work on Windows on ARM. “Lua semantics, but with more baked in by default” I understand you better now, I agree with you. As I said on the post, I was not singling Janet or your comment, it was just that it reminded me of all the times someone told me that some language will replace Lua. Sorry if my free association was bad for you.

                                  1. 3

                                    No worries. I don’t think the association will hurt me.

                                    I’ve also used Lua (specifically one of the Go-based implementations), for a CMS in the past, and I had a good run of using it with Love2D to make video games. It’s a nifty language.

                                1. 2

                                  This was a great read, and I dig the layout, style of the blog, and prose. Looking forward for more synth content here.

                                  1. 2

                                    going on lockdown again while working on “little webby press” which is my epub+site generator as a client-side webapp.

                                    1. 7

                                      This thread is so full of interesting ideas, I’m impressed. I noticed many people are very focused on aspects of the OS low-level, which is cool. On my own personal dreams, I don’t think too much about those details, I tend to focus on high-level stuff and that is what I want to share with you all.

                                      I miss Newton OS. Yes, that OS. I miss the ideas in it. Whatever mobile computing became, it is a completely different path than the one the Newton series of devices were traveling. I miss that path a lot even though I recognize the limitations of those systems (all of which could be solved with today’s hardware and software advances).

                                      • No applications: this is not exatcly true, you had applications, it is just that you could also extend applications and developers were keen to extend more than to ship siloed apps. For example, a PIM package was more likely to extend the features provided by the default address book and email applications than ship completely new apps. A good analogy is that installing a “package” on your Newton was akin to teaching it new tricks. With a curated selection of packages and configuration, you could really tailor your experience to match your needs.
                                      • Newton soups: no need for a filesystem when you have a system-wide graph database.
                                      • Simple programming language: Packages could be built with NewtonScript which for me feels like a JS cousin from the Pascal branch of the family tree. The important aspect is that it was a simple language to learn and you could provide a rich cocoa-like set of libraries, resources, and tools for this language so that development becomes very easy. Not unlike Swift and SwiftUI. Make a high-level language give it all the OS features.
                                      • User focused: Most of our “UX mental model” today is app focused or task focused. You launch an app for a specific task. I want to go back to being user-focused and by that I mean that the device provides features and the user makes whatever usage that fits their needs. An example:
                                        • There is a note taking feature on the Newton. It is a master/detail UX (like much of the Newton itself) with a list of entries and the ability to go into a specific entry for editing.
                                        • Installing a new project management package, doesn’t create “an icon to launch a project manager” (which is how it would work on an app focused OS like iOS), it extends the note taking feature with new “stationary”, a new form-type view with the fields necessary for managing projects.
                                        • You keep using the same note taking app, you just use it to add and manage your projects. New forms are also added to the calendar and other features.
                                        • The OS is extended and the user is responsible to make whatever use they want. It is about you and how you want to work and not about apps.

                                      The Newton for me is the peak of personal computing, with emphasis on the personal part. Over time each device became more and more tailored for their unique user and the way they liked working. If we add in-device development, then each user can also create their own packages which can lead to it becoming even more bespoke.

                                      A small OS for a personal experience, that is what I dream of. I bought a Raspberry Pi 400 with the hope that something like what I described can be built for it, not unlike an eMate 300 kind of experience. I don’t have the knowledge to do it, I’d probably just make the whole “OS experience” a collection of apps on top of Linux since low-level is not my stuff (the way webOS did). I’m very inspired by SerenityOS and how Andreas Kling is documenting his journey developing it. Maybe I can create a little proof-of-concept of what I’m talking about. Dreaming is very good, I do it a lot, more than I should to be honest, but at some point either I act on it or nothing changes.

                                      1. 1

                                        The update just failed for me. Apparently there is some server outage going on at Apple. It was affecting “trustd” and launching third-party apps, I don’t know how it affects the update process but it just failed to complete the download. Be aware.

                                        1. 5

                                          I remember being able to write some decent programs in Go within about two days. Julia, my current favorite was also somewhat similar. Learning Rust on the other hand felt a lot like learning Haskell. Simply a lot of concepts and theory to understand before you can do anything useful.

                                          If C++ taught me anything, it is to value simplicity, and that is not something Rust does.

                                          I strongly suspect someone is confusing simplicity and familiarity here. Granted, Rust isn’t the simplest language around. But I suspect one big reason why the author couldn’t be productive quickly was because Rust was different from what he was used to.

                                          I don’t know Rust, never programmed a single line of code. But I strongly suspect my prior experience in OCaml will help me pick it up more quickly than many other programmers. It would feel simple. But that would just be familiarity.

                                          1. 3

                                            From my limited experience, I don’t think that familiarity is the main issue here. Rust’s borrow checker usually adds a lot of friction to that initial contact with the language. Once you’ve somewhat mastered it, there is the whole set of best practices, common patterns, and just “the way people should do stuff” that is spread among various crates. They’re not part of the language but to be an effective crustacean you kinda need to learn them and when to use them.

                                            In my opinion, the journey of learning rust is trickier not because of the lack of familiarity but due to it introducing new concepts and the ways these new and old concepts interact with one another, and the ecosystem that is vast and unmapped for the newcomer.

                                            1. 2

                                              And I think my main gripe with Rust is that your suspicion is wrong. Rust is much more complex than Haskell. (Sorry, I don’t know OCaml)

                                              Some example reasons: The types are more complicated:

                                              • String vs str
                                              • u64 vs i64 You have to constantly make sure you are doing the right conversions for these and in the right way. This often means littering your code with ?, try_from and similar shenanigans. The same holds for borrowing in general, str or &str, maybe even a lifetime annotation. Sometimes you need to add to_owned somewhere. Or introduce an additional temporary variable so that the thing you are borrowing from does not die. Something I can trivially write down the way you think it should work in Haskell takes me several minutes of tinkering in Rust. It’s surprising how complicated typical functional programming constructs become when the types don’t quite fit together.

                                              Maybe there is no solution for this. Rust is just trying to give you access to every last bit of performance.

                                              From an ergonomic point of view, I find Rust incredibly interesting. Haven’t we all at some point screwed up memory management in C and angrily proclaimed the compiler should have been able to figure this out? And then the guy next to you take a sip of his Club Mate and says “Yeah, but how would the compiler know the difference between X and Y?” And you go “We just do this and this and …” And at the end of a very long night of drinking and hacking you have Rust. It is still performant and it is absolutely wonderful how many errors you cannot make anymore.

                                              Also, your dream language is now about as complicated and fun as C++. I hate it, but I am trying to get over that.

                                              1. 2

                                                String vs str

                                                One is the actual owned string, another is a pointer+size referencing a part of it, like string_view in modern C++. Easy!

                                                In Haskell, standard String is a linked list of chars, which nobody wants to use, so there’s Text and ByteString, multiply by two because each has a strict and lazy variant! Now we have five different string types, actually different (all “own” data – well it’s a GC language…)

                                            1. 3

                                              I’m dividing my time between working on my eBook generation tool and writing a novella for NaNoWriMo. They kinda feed on each other. I’m quite happy because a sample book assembled by the tool I’m building — Little Webby Press — just passed epubcheck validation for the first time. This means I’m on the right path. As for the NaNoWriMo project, sleeping is overrated!

                                              People interested in eBook generation might enjoy a little teaser video I’ve made about an early version of Little Webby Press.

                                              1. 4

                                                As someone who is building a new tool to generate ePubs right now, I feel your pain. At the same time, I’m happy that I’m not alone doing these kinds of spec juggling.

                                                1. 3

                                                  I’m disconcerted that I’ve had nobody come along and say “you’re doing it wrong, use this tool to turn an ODT or DOCX into something that passes epubcheck first time, you foolish person.” Like, not even LO’s internal ePub export passes epubcheck. I thought this would be a sufficient nerdbait …

                                                  1. 4

                                                    In my book, the more tools the better! It has been 15 minutes since a book built by my own tool passed epubcheck for the first time without any error or warning. I still need better markup for the cover and some way to generate a proper table of contents.

                                                    I’m wishing you all the luck with your books!

                                                    1. 4

                                                      This article is pretty old now but it suggests the author is using just Pandoc to create the EPUB. It’s not clear how much testing and validation they did on different ereader devices and programs, though.

                                                      1. 1

                                                        I went and tried pandoc (ver 2.5 from Ubuntu 20.04) and it did a mostly okay job from DOCX. It still messed up cross-reference endnotes, but everything does. And the output doesn’t pass epubcheck. Tralala!

                                                  1. 1

                                                    I like buying used hardware for stuff I mean to play with, such as my x230 which is running Haiku and NetBSD but for work I prefer buying new computers and extended warranty. This is possible because due to privilege and a bit of luck, I ended up in positions where the price of new machines was not a burden on me. Had I been pressed for money or on a not so comfortable situation, I’d probably go with used Thinkpads and a ton of upgrades as time goes on.

                                                    1. 1

                                                      I totally get it. I also wrote this article because - out of privilege - I was frequently given the option to spend quite a bit of money and I ended up buying hardware which wasn’t necessarily better. I also tried to mention that I only consider vendors with extended warranty, I wouldn’t necessarily buy used off of ebay.

                                                    1. 3

                                                      I just switched from homebrew to pkgsrc on my mac. I don’t need a package manager much on the mac and I bet pkgsrc will serve me well. The installation was quite straight forward. I thought about using nix on it but my past experience with it on Mac OS X was bittersweet, the potential was there but having to do backflips to appeal the shit stuff that Apple been doing with macOS proved to be too much friction to me.

                                                      1. 9

                                                        I’ve noticed the same issue with Electron apps on my low RAM devices. Anything with 4GB or less of RAM doesn’t allow you to run more than 2 instances of the programs, without chugging into swap space or worse, oom-killing.

                                                        Particularly worrying is most of my messaging apps are exactly like that: Riot/Element, FB Messenger, WhatsApp, Telegram (this last one is actually pretty optimized and doesn’t eat too much). Long gone are the days where an XMPP bridge would solve the issue, as most of the content is now images, audio messages, animated GIFs, emojis and other rich content.

                                                        Thanks for the article, at least I know that i can replace one of the culprits with a daemonized, non-Electron app and just use the phone as a remote control.

                                                        1. 9

                                                          As far as I am aware, Telegram is not Electron, it is actually a Qt based app.

                                                          1. 7

                                                            Long gone are the days where an XMPP bridge would solve the issue, as most of the content is now images, audio messages, animated GIFs, emojis and other rich content.

                                                            I’m not sure what you mean. Most XMPP clients today (like Conversations, Dino, etc.) gracefully handle all of the items you mentioned, and with much less resources than a full web browser would require. I definitely recommend XMPP bridges when possible where the only alternative is an “app” that is really a full web browser.

                                                            1. 4

                                                              Of those listed, I think Riot will maybe disappear at some point. Riot has (amazingly) managed to have native desktop clients pop up, Quarternion, gomatrix and nheko are all packaged for my Linux distribution.

                                                              1. 3

                                                                I understand the desire to use something browser-ish and cross-platform. I don’t fully understand why Electron (hundreds of mb footprint) is so popular over Sciter (5mb footprint).

                                                                1. 1

                                                                  Electron is fully free, Sciter is closed-source with a Kickstarter campaign in progress to open-source it.

                                                                  For the large companies, the price of something like Sciter should be a non-issue. If I were reviewing a proposal to use it, though, I’d be asking about security review and liability: HTML/CSS/JS have proven to be hard to get secure, Electron leverages the sugar-daddy of Google maintaining Chrome with security fixes, what is the situation with Sciter like?

                                                                  Ideally, the internal review would go “okay, but if we only connect to our servers, and we make sure we’re not messing up TLS/HTTPS, then the only attack model is around user-data from other users being rendered in these contexts, and we have to have corner-case testing there no matter which engine we use, to make sure there are no leaks, so this is all manageable”. But I can see that “manageable” might not be enough to overcome the initial knee-jerk reactions.

                                                                2. 2

                                                                  Long gone are the days where an XMPP bridge would solve the issue

                                                                  I use Dino on desktop to replace the bloated Discord & WhatsApp clients, and it works fine (with inline images, file sharing, etc working too).

                                                                  Disclaimer: I did, however, write the WhatsApp bridge :p

                                                                  1. 1

                                                                    Isn’t the reason that XMPP isn’t useful more to do with these services wanting to maintain walled gardens? And further, isn’t that a result of the incentives in a world of “free” services?

                                                                  1. 1

                                                                    This was a great introduction to Jails. I can see the appeal of it now. I think I’ll try it on a Pi at home.

                                                                    1. 1

                                                                      I’m confused. The text says it is based on FreeBSD and then makes multiple mentions of packaging the applications as AppImages and CentOS.

                                                                      1. 1

                                                                        This project is very young so its quite chaotic currently :)