1. 8

    No joke, I’m terrified that some major player in online music like Spotify, CD Baby, or Bandcamp will go out of business, and that thousands of bands will instantly vanish as if they never existed.

    I was foolishly ready to just go all-in on Spotify, until one day Dashboard Confessional’s entire back catalog vanished, with no explanation. That music was foundational to my childhood! Not being able to listen to it was completely unacceptable. It eventually returned, still with no explanation, but my trust did not. It’s one thing if a band never makes it onto Spotify for some reason, like Tool was missing for years, but it’s quite another thing when e.g. Lizzo’s early songs disappear without a trace from my playlists that I’ve carefully curated. Why can’t you listen to early Lizzo? It’s not like she’s unpopular! Where is Batches & Cookies? What do I do with this hole in my mix?

    Now I’m trying to back up all of my old CDs before they expire: https://www.vice.com/en_us/article/mg9pdv/the-hidden-phenomenon-that-could-ruin-your-old-discs Unfortunately, some of them already have scratches. I was trying to back up some of my LPs too, but that was much more of a chore and the recordings didn’t turn out that great.

    I’m trying to buy copies of the new music I care about, but it’s getting hard these days. Big names don’t have their music on Bandcamp, and there aren’t many other options for buying lossless files (which I insist upon, since preservation is my goal). Sometimes it’s still possible to buy CDs, but small bands don’t print them because the economics don’t make sense anymore. My insignificant band made the mistake of printing 1000 CDs in 2010, since that was the minimum amount to get a reasonable price on “real CDs”, and the odds that we ever sell them all is essentially zero. A run of 100 CD-Rs is doable, but those aren’t nearly as durable as pressed CDs, so why bother, if longevity is a priority?

    People need to own the books, music and other art that is an important part of their inner lives.

    1. 3

      No joke, I’m terrified that some major player in online music like Spotify, CD Baby, or Bandcamp will go out of business, and that thousands of bands will instantly vanish as if they never existed.

      A key point here is that Bandcamp at least sells you the totally unencumbered bits in whatever format you want. I download all my purchases in lossless. BIG fan of that platform.

      If they ever go away, you at least don’t lose the music you’ve already bought!

      1. 3

        Big names don’t have their music on Bandcamp

        This is mostly true, but I was delighted recently to realize that Death Cab for Cutie is on there. Some of the older Decemberists albums, too. If you’re looking for a big-name band, it’s a reasonable assumption that they aren’t on Bandcamp, but it never hurts to check.

        1. 2

          I think more and more artists are starting to see the benefits of Bandcamp.

        2. 2

          one day Dashboard Confessional’s entire back catalog vanished, with no explanation. That music was foundational to my childhood! Not being able to listen to it was completely unacceptable. It eventually returned, still with no explanation, but my trust did not. It’s one thing if a band never makes it onto Spotify for some reason, like Tool was missing for years, but it’s quite another thing when e.g. Lizzo’s early songs disappear without a trace from my playlists that I’ve carefully curated. Why can’t you listen to early Lizzo? It’s not like she’s unpopular! Where is Batches & Cookies? What do I do with this hole in my mix?

          It’s no consolation, but the internet is on position that songs disappearing from streaming services are only fault of the record companies that upload them in the first place.

          1. 3

            But there’s no transparency! There’s no changelog of “Oh yeah, here we had to take down old Lizzo songs b/c her previous record company hates her now, but they’ll be back once her old contract runs out.” It could be the record company, or it could be technical difficulties, or it could be Lizzo doesn’t like the way she used to sound and doesn’t want you to hear her old stuff. It’s a total mystery. I think that bothers me at least as much as the music disappearing.

            1. 2

              It’s no consolation, but the internet is on position that songs disappearing from streaming services are only fault of the record companies that upload them in the first place.

              Very true. Don’t kill the messenger and get angry at the streaming service, BUT it still does highlight the fact that music you care about could easily sink beneath the waves and become inaccessible to you.

              So the question then is “How much do you care?”

              For a lot of people the answer is “Not enough” but for some of us it’s worth the few hundred dollars and man days to fix the problem in a sustainable way.

          1. 1

            I’ve started buying used CDs (and DVDs) for these same reasons. I have enough storage in my laptop to carry everything with me, but I’ve wanted a phone solution, are there similar apps for Android?

            1. 3

              I use an Android music player called Odyssey. It’s not quite the same thing as the iOS app in the article, because it doesn’t automatically sync music from cloud services, but because it’s Android you can just have a bunch of music on your SD card — stick the card in your PC’s SD card reader, or connect the phone to your PC via USB, or sync music over the network with something like Dropbox or SyncThing.

              1. 1

                Most android music players will offer up anything the music indexer finds on the internal storage or SD card. They just may take a while to appear.

              1. 2

                This workflow is quite similar to my own, just with an android phone instead of an iPhone.

                I also second that Bandcamp is superb.

                1. 3

                  My old X series tablet used to do this and various other ghosting. I think it was an X270T.

                  1. 1

                    My current Thinkpad X1 5th gen is not affected by the way.

                  1. 2

                    I’d like to try something like this out… is there a vim ‘theme’ that demonstrates the ‘color free editor setup’?

                      1. 2

                        It might be his vim-colors-plain theme:

                        https://github.com/nerdypepper/vim-colors-plain

                        1. 2
                          1. 2
                            1. 1

                              to add to some of the others

                              Though I use vim-colors-plain. I’ve really enjoyed it.

                              1. 1

                                I wrote this for myself: everything is yellow, strings are red, comments are grey.

                                I remember when I started dipping into that idea – a veteran programmer ridiculed the idea of syntax highlighting. “I know what my language does, I don’t need training wheels for my editor!”

                                “What a ridiculous idea!” I thought. “Of course it’s better and easier with colours. I’ll try without them for some time just to make sure he’s wrong.” Fast forward a few weeks… he wasn’t really wrong. I’m not convinced syntax highlighting really does anything for clarity and ease of working with code. Syntax is usually instantly recognizable from the code layout alone.

                                What I’d really like to see is an editor that can highlight stuff that make semantic sense, or are meaningful in runtime. Make my slow code red and fast code green, like a highlighting code profiler, for example. Find the code not covered by unit tests and turn it red. Highlight the variable that was written to, but never read in the last 20 runs, stuff like that.

                                I can recognize syntax of my “native” programming language just fine – it’s the subtle semantics that elude me.

                                1. 0
                                  :syntax off
                                  

                                  It disables syntax highlighting.

                                  1. 2

                                    Well, sure, but the example in the article doesn’t have all coloring disabled: https://files.nerdypepper.tech/bF.png

                                    1. 3

                                      By chance I’ve been doing almost exactly the same as the OP has with my Vim colours. I just can’t stand rainbow vomit in my editor.

                                      I use it with an xterm using solarized colours.

                                      As you can see, it’s not really release-ready.

                                      (The copyright comment is that of the theme template I started with).

                                      1. 1
                                  1. 1

                                    I looked into this device a couple of years back. I needed a way to take notes and read papers.

                                    Long story short: it’s too expensive. Even after the initial purchase, you still have to buy replacement nibs for the stylus. I was also worried about the software bit-rotting: I had no idea if the manufacturers would keep up with security patches.

                                    I ended up getting an Amazon fire HD 10 for reading, and a Rocketbook Everlast for note taking.

                                    Together, these were about a third of the price of the reMarkable tablet. Admittedly, I do have to refill the Frixion pen for the Rocketbook, but still…

                                    If anyone is thinking about doing the same, I highly recommend the Xodo android app for annotating PDFs. I also tried a few different styli for the Fire, but ended up finding it easier to use a finger.

                                    1. 7

                                      Rust is indeed fun!

                                      But:

                                      I also like this “barebones” feel I felt and loved with C

                                      I can’t really agree with that. Rust is a pretty big language compared to C.

                                      1. 2

                                        It is bigger, and has some higher-level features, but at the same time it still keeps all the good low-level aspects, e.g. you can micromanage every allocation and every byte of memory you use, if you want to.

                                        Generics add a lot to the language surface, but when I don’t need to worry about goto cleanup; I have some brain cycles to spare.

                                        C feels small in number of features, but actual productive work in C requires knowing plenty of things “between the lines”, like all the places where you can cause UB, macro hacks and footguns. You still have memory management (ownership), thread safety, but without type system helping.

                                        1. 2

                                          I think you and the above poster are talking about two different things.

                                          The above poster is referring to the sheer amount of content in Rust. It is not “barebones”: the language spec, the compiler and its capabilities, and the ecosystem are all very robust and sizeable.

                                          You are referring to low-level, or “bare metal” as some would call it. Yes, Rust can get close “to the metal” but the language is not barebones.

                                          1. 1

                                            The above poster is simply misconstruing a point in the article in order to make their own point. I don’t think anybody would contend that Rust is somehow a minimalist’s language a la Scheme or Go.

                                            1. 1

                                              To clarify my position, there’s no doubt that Rust is a more productive language than C, but I wouldn’t call Rust a bare-bones language either.

                                              Sure you don’t have to use all the language features and libraries, but that doesn’t make it barebones as a unit.

                                              1. 1

                                                I also like this “barebones” feel

                                                You literally disagreed with the author feeling something

                                      1. 18

                                        I’ve worked on an open source project. Not so tiny, it used to be preinstalled with several major distros, and is still quite popular.

                                        Early 2018 we had a major CVE, with remote code execution. We had a patch ready within of 8 hours of discovery, had it tested and in our official releases within of a few days.

                                        Debian took over a month to patch it (and continued using an old version with major bugs, only patching security issues themselves). And they were the fastest. Alpine 3.7 was the first to ship the fix, and that took an eternity. Previous alpine versions (at the time still officially supported) never got the patch.

                                        Now, we’re moving towards snap/flatpak for desktop and docker for server, and building our own packages and bundles, because distro maintainers are basically useless, always ship ancient broken versions, users come to us to complain about stuff being broken (and distros refuse to ship bugfixes or versions from this decade), and the maintainers are never reachable, and even security updates are shipped at glacial speed.

                                        Honestly, distro maintainers are a massive security risk, and after this experience, I’m kinda mind blown.

                                        1. 9

                                          As an Arch packager, I can’t help but feel a little bit offended by what you said there. >:(

                                          1. 11

                                            Arch is actually one of the few distrso where this issue never existed - but that’s because arch, being rolling release, actually just uses our upstream sources, and updates frequently and reliably.

                                          2. 7

                                            because distro maintainers are basically useless

                                            That’s quite an offensive statement.

                                            1. 5

                                              If major software that’s preinstalled and in the default start menu of Kubuntu is so outdated that it has remotely exploitable bugs, months after developers have released patches for all version branches, including the one used by Debian/Ubuntu/etc, then how can you really trust the packages installed on your system?

                                              How many programs from the repos do you have installed which are not that common, or complicated to package. Are you sure they’re actually up to date? Are you sure there are no vulnerabilities in them?

                                              Ever after this, I can’t trust distros anymore.

                                              1. 3

                                                And that makes distro maintainers basically useless?

                                                1. 7

                                                  Yes. If there’s no practical value add, that statement is true.

                                                  It’s harsh to take, but yes, it’s okay to ask groups that insist on their status - especially in a role prone to gatekeeping - to stand for their value.

                                                  1. 3

                                                    If you can’t trust software distributed by your distro to be up-to-date and safe, what use does it have then? Stability is never more important than safety.

                                                    The whole point people use distributions, and especially reputable ones, is because they want to ensure (a) stuff doesn’t break, and (b) stuff is secure.

                                                    1. 2

                                                      If you can’t trust software distributed by your distro to be up-to-date and safe, what use does it have then?

                                                      Of course packagers try to keep stuff up to date and secure, but a) things move fast, and spare time and motivation can be at a premium; and b) there’s too much code to audit for security holes.

                                                      distro maintainers are basically useless

                                                      Come on now… I assure you, you’d be pretty upset if you had to build everything from source.

                                                      1. 4

                                                        Of course packagers try to keep stuff up to date and secure, but a) things move fast, and spare time and motivation can be at a premium; and b) there’s too much code to audit for security holes.

                                                        And this is where @arp242’s sentiment comes from. “In a world where there is a serious shortage of volunteers to do all of this, it seems to me that a small army of ‘packagers’ all doing duplicate work is perhaps not necessarily the best way to distribute the available manpower.”

                                                        1. 1

                                                          In a world where there is a serious shortage of volunteers

                                                          This is false. All too often it is difficult to find good software to package. A lot of software out there is either poorly maintained, or insecure, or painful to package due to bundled dependencies, or has hostile upstreams, or it’s just not very useful.

                                                          It’s also false to imply that all package maintainers are volunteers. There are many paid contributors.

                                                        2. 1

                                                          Come on now… I assure you, you’d be pretty upset if you had to build everything from source.

                                                          I don’t necessarily have to — the distro can provide a clean base with clean APIs, and developers can package their own packages for the distro. As some operating systems already handle it.

                                                2. 3

                                                  Various distributions, including Debian, backport security fixes to to stable versions even when upstream developers don’t do it. It’s not uncommon that the security fixes are released faster than upstream.

                                                  Your case is an exception. Sometimes this can be due to applications difficult to package or difficult to patch or low on popularity.

                                                  Besides, it’s incorrect to assume that the package mantainer is the only person doing security updates. Most well-known distributions have dedicated security teams that track CVEs and chase the bugs.

                                                  1. 1

                                                    We already provide backported security fixes, as .patch simply usable with git apply, and provide our own packages for old and recent branches. It’s quite simple to package too. Popularity, well, it was one of the preinstalles programs on Kubuntu, and is in Kubuntus start menu (not anymore recently, but on older versions it still is).

                                                    The fact that many distro maintainers still take an eternity updating patches, and sometimes not even apply those, makes relying on distro packages quite an issue. I don’t trust distro maintainers anymore, not after this.

                                                  2. 3

                                                    Honestly, distro maintainers are a massive security risk, and after this experience, I’m kinda mind blown.

                                                    I think this is mostly because you have a one-sided experience of this and it’s most likely a bit more nuanced and down to several factors.

                                                    One of them being that the CVE system is broken and hard to follow. How did you disclose and announce the CVE and fix? Did the patches need backports for the given release and where those provided? I don’t know the CVE number, so this is hard to followup on. But the best approach is to announce on a place like oss-sec from open-wall and it should be picked up by all distribution security teams.

                                                    The other side of this, which is what distribution maintainer see, but few upstreams realize, is patching dependencies is where most of the work is done. Distributing your app as a snap/flatpak works great if you also patch the dependencies and keep track of security issues with those dependencies. This is where most upstreams fails, and this is where distribution maintainers and the distro security teams improve the situation.

                                                    1. 1

                                                      The other side of this, which is what distribution maintainer see, but few upstreams realize, is patching dependencies is where most of the work is done. Distributing your app as a snap/flatpak works great if you also patch the dependencies and keep track of security issues with those dependencies

                                                      That’s why, if you ever build such images yourself, you need to automate it, have it as CI, and update those dependencies at least daily, and generate a new image whenever new dependencies are available. Obviously, you need automated tests in your build procedure to ensure everything still works together, as sometimes some dependencies break important stuff even in patch releases.

                                                      How did you disclose and announce the CVE and fix? Did the patches need backports for the given release and where those provided

                                                      We provided patches for every version distros used, as nice patch files that could directly be applied with git apply, and in addition to the more common ways, we also directly contacted the package maintainers for our package for the important distros via email or instant messaging.

                                                      In general, personally, I’m not a fan of the stable model anyway, though. We’ve done great work to ensure the software stays 100% binary compatible for all its protocols since 2009, we support every supported version of debian and ubuntu even with our absolutely newest builds, and yet, in the end, it’s the distro maintainers shipping not only outdated versions (apparently some users prefer buggy old versions), but also take time to apply security fixes.

                                                      1. 2

                                                        That’s why, if you ever build such images yourself, you need to automate it, have it as CI, and update those dependencies at least daily, and generate a new image whenever new dependencies are available. Obviously, you need automated tests in your build procedure to ensure everything still works together, as sometimes some dependencies break important stuff even in patch releases.

                                                        Which again, few upstream do this, and they surely do not keep an eye on this at all. You sounds like a competent upstream and it’s nice when you encounter them :)

                                                        We provided patches for every version distros used, as nice patch files that could directly be applied with git apply, and in addition to the more common ways, we also directly contacted the package maintainers for our package for the important distros via email or instant messaging.

                                                        And this is how you should proceed. I would however contact the linux distro list if it’s a widely used piece of software multiple distributions package, and the CVE is critical enough. https://oss-security.openwall.org/wiki/mailing-lists/distros

                                                        In general, personally, I’m not a fan of the stable model anyway, though. We’ve done great work to ensure the software stays 100% binary compatible for all its protocols since 2009, we support every supported version of debian and ubuntu even with our absolutely newest builds, and yet, in the end, it’s the distro maintainers shipping not only outdated versions (apparently some users prefer buggy old versions), but also take time to apply security fixes.

                                                        The work is appreciated, but I’ll still urge you to not let one bad experience ruin the whole ordeal. Distribution security teams is probably one of the least resourceful teams and sometimes things do fall between two chairs.

                                                        1. 3

                                                          The work is appreciated, but I’ll still urge you to not let one bad experience ruin the whole ordeal. Distribution security teams is probably one of the least resourceful teams and sometimes things do fall between two chairs.

                                                          But given that the main argument of distros is security, that statement flies directly in the face of their promises.

                                                          1. 2

                                                            But given that the main argument of distros is security, that statement flies directly in the face of their promises.

                                                            I don’t think it’s the main argument, but surely one them. If you want to be completely covered you need a well paid team able to respond. You wont get this with community based distribution, we are unpaid volunteers, just like most upstreams. You’ll have to use something backed by a paid team if you expect premium service and full coverage.

                                                            Anything else is only on a best effort basis. The CVE system is sadly hard to navigate, ingest and process. Some things are going to bubble up faster, and something is going to be missed.

                                                            1. 2

                                                              I have absolutely no issue with all your statements, but it is a cornerstone argument.

                                                              I’m fine with community distributions, if they own it, and agree that paid distros are a good way to go. RHEL licenses are actually worth their money.

                                                              I disagree with the reading of best-effort, though, because it goes both ways. If your work is impacting others, either through making them have more support requests or slowing down their iteration speed, you need to make sure you don’t add undue labor.

                                                    2. 3

                                                      With this attitude, which a lot of developers seem to have nowadays, it doesn’t make sense to have your software included in distributions. As a packager I’d call this a hostile upstream… Just distribute it as a flatpak and/or snap and be done with it.

                                                      Relevant here may be a blog post from an upstream fully embracing the distribution instead of fighting it: https://www.enricozini.org/blog/2014/debian/debops/

                                                      1. 3

                                                        It allows me to rely on Debian for security updates, so I don’t have to track upstream activity for each one of the building blocks of the systems I deploy.

                                                        That’s exactly what I used to believe in, too, but after this experience, the facade has cracked. I can deal with 90% of my packages being years out of date and full of bugs because the distro wants to be stable and refuses to apply bugfixes or update to newer versions, but if security updates aren’t reliably applied even if they have a CVE (and debian just ignores issues entirely if they have no CVE), then how can one still trust the distro for security updates? Having a remotely exploitable unauthenticated DoS if not even RCE in a publicly facing software for 30 days is absolutely not fine.

                                                        As a packager I’d call this a hostile upstream… Just distribute it as a flatpak and/or snap and be done with it.

                                                        We actively maintain all version branches, and provide even backported security patches as nice little .patch file even for all the major.minor.patch releases debian/ubuntu still use. You can build it nice and simple, you just have to apply one little patch. It’s not like this we’ve been actively hostile - what more should we have done, in your opinion?

                                                        1. 2

                                                          how can one still trust the distro for security updates?

                                                          Fair enough. If they are not applied. I personally know at least one Debian package maintainer (not me, I don’t like Debian) that takes excellent care of their packages, including in the stable releases. So it may depend on the maintainer. But maybe that is your point, that there is no universal standard for maintainers…

                                                          what more should we have done, in your opinion?

                                                          I don’t know this specific case. There are a number of other ‘historical’ cases where packagers gave up on packaging ‘upstream’ software, e.g. https://www.happyassassin.net/2015/08/29/looking-for-new-maintainer-for-fedora-epel-owncloud-packages/. I also wrote a blog post about it in 2016: https://www.tuxed.net/fkooman/blog/owncloud_distributions.html I guess the best one can do is follow these discussions and if possible make it easier for distributions to package the software. Especially the ownCloud case back then bugged me a lot. But as you can see from some other people in those discussions, we just gave up on ownCloud and used something else instead…

                                                    1. 2

                                                      The difference in trust between managed software repositories like Debian, Alpine Linux, Fedora, and so on; and unmanaged software repositories like PyPI, npm, Chrome extensions, the Google Play store, Flatpak, etc — is starkly obvious. Debian and its peers are full of quality software which integrates well into the host system and is free of malware. Unmanaged repositories, however, are constant sources for crapware and malware.

                                                      Interesting. I’d never made the distinction between managed unmanaged repos before.

                                                      Obviously a managed repo is preferred, but as he says, you need a dedicated team of (usually unpaid) porters on-hand to create and maintain binary packages. Not to mention the additional infrastructure. Whereas the unmanaged repos are effectively crowd-sourced…

                                                      Food for thought.

                                                      1. 1

                                                        I use one called poole. It seems to be unmaintained though: https://bitbucket.org/obensonne/poole/pull-requests/

                                                        I recently raised a PR to fix some Python3 stuff, but it has just sat there…

                                                        1. 3

                                                          Are there any alternative clients without Javascript?

                                                          1. 3

                                                            It seems like this is just an email client, so you could presumably use any email client?

                                                            1. 2

                                                              Yes, this is the whole point. It’s an e-mail client that has UI affordances for instant messaging.

                                                          1. 2

                                                            I have a system that I use in a Rocketbook Everlast. My system takes (what I believe to be) the best parts of Bullet Journal, but cans the parts I find inefficient and unnecessary.

                                                            • Each week I split a page into three sections:

                                                              • Work
                                                              • BSD
                                                              • Personal
                                                            • Each section uses the bullet system similar to bullet journal:

                                                              • . for a task.
                                                              • o for an event
                                                              • Add an additional * for emphasis (to prioritise).
                                                              • / a . to indicate you started the task.
                                                              • Convert a task or event to a x when the task or event is done
                                                              • At any time you can strike out a line to cancel it.
                                                            • At the beginning of a week, I review the previous week’s page and either:

                                                              • Strike out a task that isn’t worth my time any more.
                                                              • > (triangle) a task I’m going to carry forward to the current week (in bullet journal they call that migration).
                                                            • Then I use the Rocketbook app to scan the page, pull the scan up on my computer and copy the migrated tasks onto a new week’s page.

                                                            I also have a ribbon tied to the notepad for quick access to the current week’s page. This is particularly useful for a Rocketbook Everlast, which is effectively a ring buffer.

                                                            I’ve used this system for about 6 months so far. I find the Monday morning ritual of reviewing my progress and adjusting my priorities to be a good way of getting my head in the right mode for the coming week. The review takes about 5-10 minutes.

                                                            I found bullet journal to be too regimented for my taste, and setting up the journal looks like it takes an age. Also I want my notebook to be a place where I can scribble unstructured notes, trees, graphs and diagrams etc. With my system any blank page can be used for those kinds of notes, and planning only takes up a page here and there between other notes.

                                                            1. -1

                                                              I’ve been meaning to delete my keybase account for some time now. I don’t use it, and last time I tried to, it wanted to add a uid to my keys, which I didn’t want.

                                                              1. 45

                                                                RustTL;DR: It’s a very impressive language with a clear vision and priorities, but the user interface needs a lot of work. Also, the collection library is much better than Scala’s.

                                                                • Generics with <>. It’s 2017 by now, we know it’s a bad idea. One of the reasons why the language suffers from abominations like the “turbofish” operator ::<>.

                                                                • Strings don’t offer indexing, because it doesn’t make sense for UTF-8. Correct! But Strings offer slicing … WAT?

                                                                • Misuse of [] for indexed access. Having both () and [] doing roughly the same thing, especially since [] can be used to do arbitrary things, doesn’t make sense. Pick one, use the other for generics.

                                                                • Inconsistent naming. str and String, Path and PathBuf etc.

                                                                • :: vs. . is kind of unnecessary.

                                                                • Mandatory semicola, but with some exceptions in arbitrary places: struct Foo; vs. struct Foo {}

                                                                • Arbitrary abbreviations all over the place. It’s 2017, your computer won’t run out of memory just because your compiler’s symbol table stores Buffer instead of Buf.

                                                                • Can someone decide on a casing rule for types, please, instead of mixing lowercase and uppercase names? Some types being “primitive” is an incredibly poor excuse.

                                                                • Also, having both CamelCase and methods_with_underscores?

                                                                • Library stutter: std::option::Option, std::result::Result, std::default::Default

                                                                • iter(), iter_mut(), into_iter() … decide prefix or postfix style and stick with it.

                                                                • Coercions do too many things. For instance, they are the default way to convert i32 to i64, instead of just using methods.

                                                                • Also, converting numbers is still broken. For instance, f32 to i32 might result in either an undefined value or undefined behavior. (Forgotten which one it is.)

                                                                • Bitcasting integers to floats is unsafe, because the bits could be a signaling NaN, causing the CPU to raise an FP exception if not disabled.

                                                                • Forward and backward annotations: #[foo] struct Foo {} vs struct Foo { #![foo] }. Also /// for normal documentation, //! for module level documentation. Documentation already uses Markdown, so maybe just let people drop a markdown file in the module dir? That would make documentation much more accessible when browsing through GitHub repositories.

                                                                • Also, documentation can cause compiler errors … that’s especially fun if you just commented a piece of code for testing/prototyping.

                                                                • Type alias misuse: In e.g. io crate: type Result<T> = Result<T, io::Error> … just call it IoResult.

                                                                • Macros are not very good. They are over-used due to the fact that Rust lacks varargs and abused due to the fact that they require special syntax at call-site (some_macro!()).

                                                                • Pattern matching in macros is also weird. x binds some match to a name in “normal” pattern matching, but matches on a literal “x” in “macro pattern matching”.

                                                                • println! and format! are very disappointing given that they use macros.

                                                                • Compiler errors … ugh. So many things. Pet peeve: “Compilation failed due to 2 errors” … 87 compiler errors printed before that.

                                                                1. 8
                                                                  • Library stutter: std::option::Option, std::result::Result, std::default::Default
                                                                  • Type alias misuse: In e.g. io crate: type Result<T> = Result<T, io::Error> … just call it IoResult.

                                                                  How ya gonna square that circle?

                                                                  1. 2

                                                                    I think std::io::IoResult would be fine – it would solve the issue of having vastly different Results flying around, while not having single-use namespaces that are only used by one type.

                                                                    1. 2

                                                                      The general pattern is to import Io instead. When doing this, IoResult would be jarring.

                                                                      use std::io;
                                                                      
                                                                      fn my_fun() -> io::Result<T> {
                                                                      
                                                                      }
                                                                      
                                                                  2. 14

                                                                    It’s 2017,

                                                                    I have some news for you, @soc.

                                                                    1. 3

                                                                      Haha, good catch. Now you see how old this list is. :-)

                                                                      The only thing I got to delete since then was “get rid of extern crate”.

                                                                    2. 3

                                                                      What’s your preferred alternative to generics with <>?

                                                                      1. 6

                                                                        [], as it was in Rust before it was changed for “familiarity”.

                                                                        Unlike <>, [] has a track of not being horribly broken in every language that tried to use it.

                                                                        1. 5

                                                                          How is <> broken?

                                                                          1. 16

                                                                            It complicates parsing due to shift and comparison operators.

                                                                            1. 2

                                                                              Ah, yeah, that makes sense.

                                                                            2. 19

                                                                              Pretty much no language has ever managed to parse <> without making the language worse. The flaws are inherent in its design, as a compiler author you can only pick where you place the badness; either:

                                                                              • Add additional syntax to disambiguate (like ::<> vs. <> in Rust).
                                                                              • Have weird syntax to disambiguate (like instance.<Foo>method(arg1, arg2) in Java).
                                                                              • Read a potentially unlimited amount of tokens during parsing, then go back and fix the parse tree (like in C#).
                                                                              • etc.

                                                                              In comparison, here are the issues with using [] for generics:

                                                                              • None.

                                                                              For newly created languages (unlike C++, which had to shoehorn templates/generics into the existing C syntax) it’s a completely unnecessary, self-inflicted wound to use <> for generics.

                                                                              More words here: Why is [] better than <> for generic types?

                                                                              1. 2

                                                                                Those are good reasons to not use <>, but as a Haskeller I personally find either style somewhat noisy. I’d rather just write something like Option Int. Parentheses can be used for grouping if needed, just like with ordinary expressions.

                                                                                1. 2

                                                                                  Haskell feels like it is in the same category as D, they both just kicked the can a tiny bit further down the road:

                                                                                  Both need (), except for a limited special-case.

                                                                                  1. -1

                                                                                    I don’t see how Haskell kicked the can down the road. The unit type is useful in any language. Rust has a unit type () just like Haskell. Scala has it too.

                                                                                    I’m not sure what “special case” you are referring to.

                                                                                    1. 2

                                                                                      The fact that you still need () for grouping types in generics as soon as you leave the realm of toy examples – just as it is in D.

                                                                                      (Not sure what’s the comment on the unit type is about…)

                                                                                      1. 4

                                                                                        Ah, I understand what you’re saying now. But that’s already true for expressions at the value level in most programming languages, so personally I find it cleaner to use the same grouping mechanism for types (which are also a form of expressions). This is especially applicable in dependently typed languages where terms and types are actually part of the same language and can be freely mixed.

                                                                                        However, I can also appreciate your argument for languages with a clear syntactic distinction between value expressions and type expressions.

                                                                          2. 1

                                                                            D’s use of !() works pretty well. It emphasizes that compile-time parameters aren’t all that crazy different than ordinary runtime parameters.

                                                                            1. 1

                                                                              I prefer my type arguments to be cleanly separated from value arguments (languages that fuse them excepted).

                                                                              I find D’s approach slightly ugly, especially the special-cases added to it.

                                                                              1. 1

                                                                                I prefer my type arguments to be cleanly separated from value arguments

                                                                                Well, in D they aren’t type vs value arguments, since you can pass values (and symbol aliases) as compile-time arguments as well. That’s part of why I like it using such similar syntax, since it isn’t as restricted as typical type generics.

                                                                                I find D’s approach slightly ugly, especially the special-cases added to it.

                                                                                The one special case is you can exclude the parenthesis for a single-token CT argument list and actually I thought I’d hate it when it was first proposed and I voted against it… but now that it is there and I used it, I actually like it a lot.

                                                                                Sure does lead to a lot first timer questions on the help forums though… it certainly isn’t like any other language I know of.

                                                                          3. 2

                                                                            Also, converting numbers is still broken. For instance, f32 to i32 might result in either an undefined value or undefined behavior. (Forgotten which one it is.)

                                                                            Yeah, I kind of feel the same way. Even with try_from() dealing with number conversions is a pain in Rust.

                                                                            1. 1

                                                                              You saved me a lot of typing. 100% agree.

                                                                              1. 1

                                                                                Thanks! I’d love to know the reason why someone else voted it down as “troll” – not because I’m salty, but because I’m genuinely interested.

                                                                              2. 1

                                                                                2 pains I have with Rust right now:

                                                                                • I would like to be able to connect to a database (Teradata specifically)
                                                                                • I want to launch a subprocess with other than the default 3 stdio descriptors (e.g. exec $CMD $FD<>$PIPE in sh)
                                                                                1. 2

                                                                                  I know it’s technically unsafe and that might preclude it from your use, but does CommandExt::pre_exec not fit your bill?

                                                                                  1. 2

                                                                                    That could work. I’m still new to Rust so I haven’t fully explored the stdlib.

                                                                                2. 1

                                                                                  Ahahaha, this is a great list. I’m curious about a couple things though, since you’ve obviously put a lot of thought into it…

                                                                                  Bitcasting integers to floats is unsafe, because the bits could be a signaling NaN, causing the CPU to raise an FP exception if not disabled.

                                                                                  The docs for f32::from_bits() and such talk about precisely this, but I considering the misdesign of signaling NaN’s really don’t see how it could possibly be made better. Any ideas?

                                                                                  …They are over-used due to the fact that Rust lacks varargs…

                                                                                  What little experience I have with programming language design makes me feel like varargs are a hard problem to deal with in a type-safe language, at least if you want to allow different types for the args (instead of, say, forcing them all to be what Rust would call &dyn Display or something). Do you know of any language which does it Right?

                                                                                  1. 1

                                                                                    The docs for f32::from_bits() and such talk about precisely this, but I considering the misdesign of signaling NaN’s really don’t see how it could possibly be made better. Any ideas?

                                                                                    Rust could have disabled the trapping of signaling NaN’s on start up, but I think Rust fell into the same design mistake of C:

                                                                                    Scared of making the use-case of the 0.01% (people who want signaling NaN’s to trap) harder to achieve, they made life worse for the 99.99%.

                                                                                    varargs are a hard problem to deal …

                                                                                    Agreed, it’s safe to say that language designers hate them. :-)

                                                                                    … at least if you want to allow different types for the args

                                                                                    I think this is only partially the reason. You can still have only same-typed varargs at runtime, but allow recovering the individual types of the arguments in macro calls – which is exactly the case for format! and friends.

                                                                                    Do you know of any language which does it Right?

                                                                                    I think in the case of format strings, focusing on varargs is the wrong approach. If you imagine how you want an ideal API to look like, you probably want to interpolate things directly inside the string, never having to go through the indirection of some vararg method.

                                                                                    Instead of having the formatting parameters in one place, and the to-be-interpolated values in a different one, like in …

                                                                                    let carl = "Carl"
                                                                                    let num = 1.234567;
                                                                                    format!("{}'s number is {:.*}, rounded a bit", carl, 2, num)
                                                                                    // -> "Carl's num is 1.23, rounded a bit"
                                                                                    

                                                                                    … wouldn’t it be much nicer to write (this is Scala):

                                                                                    val carl = "Carl"
                                                                                    val num = 1.234567
                                                                                    f"$carl's num is $num%.2f, rounded a bit"
                                                                                    // -> "Carl's num is 1.23, rounded a bit"
                                                                                    
                                                                                    1. 1

                                                                                      Julia has nice string interpolation too. I honestly don’t understand why more programming languages don’t have it. Does everyone just forget how useful it is in bash when they come to design their language?

                                                                                1. 1

                                                                                  Has anyone managed to get on the “general” mailing list for this project?

                                                                                  1. 1

                                                                                    Fixed :) Sorry for the noise.

                                                                                  1. 12

                                                                                    I’ve been evaluating sourcehut recently and I was involved in the Neovim/OpenBSD CI integration.

                                                                                    The testing infrastructure is really good and it’s really simple to fire up VMs running different BSDs and Linuxes. I much prefer it to travis, which is just a pain to set up.

                                                                                    The git side of things is very minimal, and you won’t see things like pull requests (they recommend using the email workflow). If you want PRs, then you can integrate sr.ht with GitHub. Personally I prefer the PR workflow and my guess is that the majority of others would too. Nonetheless, I moved one personal project (for which I don’t expect collaboration) to sr.ht and it all seems to work fine. Perhaps a little slow to push, but that’s geography for you.

                                                                                    I’ve not played with the mailing lists or todos much yet.

                                                                                    I’d say I’m likely to donate, as I’d like to see a BSD-friendly github alternative succeed.

                                                                                    1. 15

                                                                                      I am really pleased with sourcehut. Neovim project needed CI for OpenBSD and FreeBSD. I was dreading the yak-shaving, but spent ~20 minutes and now we are set up: https://builds.sr.ht/~jmk/neovim

                                                                                      1. 2

                                                                                        Agreed. It was very simple :)

                                                                                      1. 6

                                                                                        The number of times I’d wished I had this feature on Travis.

                                                                                        Instead you just end up blindly pushing changes to the branch in the hope that it works :P

                                                                                        1. 4
                                                                                          1. 3

                                                                                            Only on Travis-ci.com (the paid version), and not Travis-ci.org (the free version).

                                                                                            1. 4

                                                                                              sr.ht is also a paid service, right?

                                                                                              1. 4

                                                                                                It’s up to you whether to pay or run the exact same free software on your own infra.

                                                                                                1. 2

                                                                                                  Is it easy to run on your own? That’s kind of cool. I may pay them anyway but still run it myself.

                                                                                                  1. 9

                                                                                                    https://man.sr.ht/installation.md

                                                                                                    Reach out to the mailing list if you run into trouble :)

                                                                                                    1. 1

                                                                                                      Wow, cool! Thanks :)

                                                                                                  2. 1

                                                                                                    You can also run travis-ci.org on your own infra (I currently do this) but there isn’t a lot of info about it.

                                                                                                2. 3

                                                                                                  The trick is that for public repos, you have to email support: https://docs.travis-ci.com/user/running-build-in-debug-mode/#enabling-debug-mode

                                                                                                  1. 1

                                                                                                    Weird… I guess that they’re trying to prevent wasted containers by adding manual process in the middle?

                                                                                                    1. 2

                                                                                                      It’s a security risk, especially for public repos.

                                                                                                      1. 2

                                                                                                        Eeeek, that’s rough. builds.sr.ht’s SSH access uses the SSH keys we already have on your account for git authentication et al.

                                                                                                        1. 1

                                                                                                          You get that from Github, too. But I also think it doesn’t help, because GH projects are liberal with adding people to orgs/repos and while they cam be grouped, there’s no way to assign structures roles. GH as an identity provider is mediocre at best.

                                                                                                        2. 1

                                                                                                          Like, in terms of things which they may do in the shells, DDoSing by creating too many, etc? They use your SSH key from GitHub to prevent others from SSHing in, right?

                                                                                                          1. 4

                                                                                                            They use your SSH key from GitHub to prevent others from SSHing in, right?

                                                                                                            Not AFAIR. It gives a temporary login/password in the build log (which is public). And anyone who logs in can see the unencrypted secrets (e.g. API keys used for pushing to GitHub).

                                                                                                            1. 1

                                                                                                              oooooooh… yipes. Super dangerous. CircleCI uses SSH keys to improve on this.

                                                                                                    2. 1

                                                                                                      Aren’t they doing some funky reorganization to eliminate the split? I haven’t looked closely so I might be wrong.

                                                                                                    3. 2

                                                                                                      I guess I’ve just been too cheap to pay then ;)

                                                                                                    4. 1

                                                                                                      This feature is on Travis, but their new configuration API is so excruciatingly painful and lacking of reasonable documentation that it fails to help when it’s really needed.

                                                                                                      1. 1

                                                                                                        With Gitlab you can debug CI stages on your machine by starting a local Gitlab Runner.

                                                                                                      1. 1

                                                                                                        One of those weird git hosting sites that don’t put code first. And that file browser’s is really bad. Who sorts files and directories alphabetically? Usually you put directories first.

                                                                                                        1. 2

                                                                                                          And that file browser’s is really bad. Who sorts files and directories alphabetically?

                                                                                                          I feel this isn’t totally fair. There’s a big red box on the front page that makes it quite clear that it’s early days for development:

                                                                                                          Achtung! Sourcehut is still under heavy development, and while many of the services are usable, expect to find lots of missing polish, broken links, incomplete docs, and so on. Here be dragons!

                                                                                                          Why don’t you submit an issue?

                                                                                                          1. 1

                                                                                                            I feel this isn’t totally fair. There’s a big red box on the front page that makes it quite clear that it’s early days for development

                                                                                                            Fair to who? Its just obvious flaws.

                                                                                                            Why don’t you submit an issue?

                                                                                                            I don’t really care.

                                                                                                        1. 3

                                                                                                          Privacy:

                                                                                                          When you host your own mailserver, you truly own your email without having to rely on any third-party.

                                                                                                          Yeah, not really.

                                                                                                          • If you send email to someone with a Gmail address, then Google reads the email.
                                                                                                          • If someone send you an email from a Gmail address, Google reads the email.

                                                                                                          Only in a scenario where both parties own their infrastructure do you get the privacy gain the author assumes. Even then, you have to trust that the third party has good intentions and sound security practices.

                                                                                                          I think the best approach to (unencrypted) email is to assume that anyone can read it.

                                                                                                          1. 1

                                                                                                            I still relay outgoing mail through Google (most of which is to public mailing lists or GMail accounts anyway), but I set up a receive‐only mail server last month, and now Google no longer has access to my sales receipts, my utility bills, my flight itineraries, nor knows all the mailing lists I subscribe to. That’s a big win in my book, even if email is ultimately unsecurable.