[HN Gopher] Debian 11
___________________________________________________________________
Debian 11
Author : marcodiego
Score : 422 points
Date : 2021-08-14 12:21 UTC (10 hours ago)
(HTM) web link (www.debian.org)
(TXT) w3m dump (www.debian.org)
| Shish2k wrote:
| PHP 8.0 is 10 months old, and debian's upcoming release will be
| upgrading from 7.3 to 7.4, which will make 7.4 the standard for
| the next ~3 years (even though it only gets upstream support for
| 1 more year)...
|
| I am starting to reconsider my personal policy of "use debian-
| stable as a benchmark for what language runtimes I should build
| on top of", now tending towards "use debian stable as the bare-
| metal OS, and build all my projects inside docker, using each
| language's most recent stable release"
| dmd wrote:
| Meanwhile, over here in healthcare, I'm currently carefully
| evaluating whether to update some software packages from their
| 2011-release version to their 2015-release version (which are
| 99.9% compatible but add one or two new features).
|
| And many of our critical systems (mostly MRIs) are on RHEL 5.
| (Not connected to any network, don't worry!)
| goodpoint wrote:
| as user5994461 wrote that's a bit too extreme in the opposite
| direction.
|
| However, most people don't realize that the majority of the
| software deployed in the world is meant to run for years
| without getting feature updates.
|
| Most production code is running on servers, vehicles,
| industrial systems, infrastructure, military stuff and so on.
| Planes and power plants can have an expected lifetime of 40
| years.
|
| Case in point: the civil infrastructure project
| https://www.cip-project.org/ plans to maintain a Debian-
| derived kernel and basic OS and backport security updates for
| 25 years.
| midev wrote:
| > Meanwhile, over here in healthcare, I'm currently carefully
| evaluating whether to update some software packages from
| their 2011-release version to their 2015-release version
|
| This could partially explain why healthcare IT is some of the
| worst in the world. Can't imagine the number of
| vulnerabilities you have from using such outdated tech.
|
| From EHR systems, to basic appointment scheduling, to billing
| and insurance, everything is so poorly built and tedious for
| the users. Not to mention, healthcare is always falling
| victim to ransomware, shutting down entire hospital systems.
|
| I know you'll say you need to move slow, lives are at risk,
| etc. But what healthcare IT is doing now certainly doesn't
| work. So maybe push on the gas a little bit.
| user5994461 wrote:
| That's a bit too extreme in the opposite direction. :D
|
| For those wondering what features are missing from RHEL 5,
| look further than SSL.
| dmd wrote:
| Fortunately nobody has ever needed to access the internet
| from these machines.
|
| People on HN forget that a huge amount of computing has
| nothing whatsoever to do with the web.
| inglor_cz wrote:
| In 2002, I underwent a LASIK operation on a machine that
| ran Windows for Workgroups. I believe the same machine
| was in use until 2012 or so.
| user5994461 wrote:
| Expect all healthcare machines to be networked, even if
| only internally. Need the active directory to login and
| need to upload the image/test sample somewhere else after
| it's taken. That's sadly one reason why ransomware can
| propagate so easily and stop hospitals. :(
|
| In theory there can be computers with no network,
| typically an isolated computer attached to heavy test
| machinery, but it's becoming impossibly rare in all
| industries.
|
| And they should be easy to recognize, look for the post-
| it nearby with the shared username/password to unlock it,
| also notice the doctors leaving with the x-ray printed on
| paper or a USB key to be able to transfer it elsewhere.
| wallaBBB wrote:
| This if done is usually against the manufacturer's
| directives (if even possible to put online). The
| equipment that has networking capabilities is designed
| for internal networks, physically isolated, and it's a
| big emphasis on this coming from the OEMs.
|
| Changing/maintaining SW in medical devices is not easy
| (FDA, CE...) and as many mentioned, not everything is
| designed to move like the web...
| umvi wrote:
| Getting your doctors off internet explorer would be a good
| start
| dmd wrote:
| But IE7 hasn't been sufficiently tested for enterprise yet!
| j/k don't worry they're all on Edge.
| samueloph wrote:
| Seems like you should take a look at https://deb.sury.org/
|
| PHP 8.0's release wasn't long ago enough to fit into the stable
| release, bullseye was too close to the initial freeze period
| when that happened.
| regularfry wrote:
| That is the correct approach. Docker optional, but language
| interpreters included with the OS _are for the OS_. The
| distribution is there to provide a mutually compatible set of
| working applications for end users so they don 't have to care
| about matching package versions by hand.
|
| Unless what you're doing is writing an application to be
| packaged with Debian, the version shouldn't matter to you:
| /usr/local is there, use it.
|
| (note: none of this is "official" in any way, just what I've
| learned over 15 years or so of deploying on Debian-derived
| distros)
| ncphil wrote:
| IMHO, that is the correct approach no matter the distro. The
| OS is a platform, the software included with it should be
| what works best to support that platform during a given
| release cycle. Anything beyond that can be addressed by
| containers, or third-party package repositories (including
| your own personal repo). It may be a biased perspective from
| the server side, but give it credit for being based on long,
| hard experience with frightening permutations (as in ugly,
| prone to misbehaving, many-headed beasts supporting critical
| services).
| dannyobrien wrote:
| I'm similar, except that I use Debian as the underlying system,
| and install with Guix. I imagine it's the same with Nix folks.
|
| I'm still unsure whether Docker injects that much more
| complexity and runtime burdens, but it sure feels a little more
| messy after installing a few tools.
| roenxi wrote:
| I'll opine, happily, that nothing showcases the gap between the
| OS people and the Web people as well as someone who considers
| 10 months to be a significant length of time.
|
| There is a happy day coming for the web developers, sometime
| this decade hopefully, when skills learned as long as 12 months
| ago will still be up to date.
|
| Did you notice OpenJDK has been upgraded from v11 to v11? That
| sort of radical change is why I run Debian. They don't break
| stuff.
| elipsey wrote:
| When I was an intern there was this old dude who had an
| ancient computer with the same Debian on it for like 7 years.
| He never got excited about new stuff, and just didn't want to
| break anything. I thought that was kind of funny and un-hip,
| back then, but now I'm like that. It's like Dad OS. :)
| burntsushi wrote:
| I'm a Dad and I use Arch. I can't stand non-rolling release
| Linux distros. They are constantly getting in my way
| because they don't track upstream.
|
| I have multiple machines running Arch (some over a decade)
| with no problems. In constrast, doing dist upgrades on
| Ubuntu has put me into states that I could not figure out
| how to get out of, and thus had to do a clean install.
| (Granted, it's been a long time since this has happened,
| but mostly because I very specifically avoid non-rolling
| release distros.)
| zozbot234 wrote:
| Ubuntu upgrades are extremely messy compared to Debian.
| If you want a rolling-like experience, the testing
| channel of Debian is pretty good for that - though it
| does get frozen when approaching a stable release.
| burntsushi wrote:
| The dist upgrade is more of an example meant to dispel
| the myth that non-rolling release distros break less
| frequently than rolling release. Or at least, an anecdote
| anyway.
|
| Jumping down from the meta level of rolling vs non-
| rolling, I personally find Archlinux style of packaging
| much much simpler than Debian's. I've writte numerous
| PKGBUILD files over the years and it's been dead simple.
| But my eyes gloss over whenever I look at Debian
| packages.
|
| I'm sure the complexity in Debian is warranted for one
| reason or another. But it ain't for me.
| mwcampbell wrote:
| I think the web people have the right idea. If it hurts, do
| it more often [1], right?
|
| I've used Debian for a long time (edit: on servers), but the
| short (and in some cases getting shorter) release cycles of
| popular projects like Chromium and Rust have got me wondering
| if Debian just moves too slow. I'm tempted to try using
| Fedora as a container base image and see if it's practical to
| keep up. Edit: I guess Fedora is no worse than Alpine if you
| actually update to each new major release quickly, since they
| both release every 6 months.
|
| [1]: https://www.martinfowler.com/bliki/FrequencyReducesDiffi
| cult...
| qwertox wrote:
| It is possible that if you build up a routine to always
| stick to the latest, it will become an automatism. This
| opens the door to several types of risks.
|
| Containers are always an option.
| murgindrag wrote:
| No, the web people have it wrong. It's called:
|
| - Failure to do upfront design (yay, misinterpreted
| agile/MVP/etc)
|
| - Reinventing wheels over, and over, and over
|
| Newer versions and frameworks tend to be 10% improvement,
| and 90% unnecessary churn.
| miohtama wrote:
| Static binaries like Snap, macOS, etc. solve "moving
| slowly" issue. There should be little need to update the
| core OS (kernel, initd, /etc stuff) often.
| Shish2k wrote:
| Very fair point :) All my other dependencies, using 5 year
| old versions is fine; it's mostly just PHP that gets an order
| of magnitude less-painful to work with in each release, so
| being stuck a few versions behind is extra frustrating...
| slim wrote:
| That's because php decided it needs 6 month release cycles
| now. You're better off targeting php 7.4 for the next 3
| years imho
| jorams wrote:
| PHP releases once a year. They've been doing that for
| almost a decade now.
| CogitoCogito wrote:
| Is it that difficult to build and/or install a newer
| version that better fits your needs? I tend to stick to
| debian stable, but in the few cases where I need newer
| software I just build it myself. Using `apt build-dep
| [package]` and then something along the lines of `configure
| && make && make install` basically always works.
|
| edit: I guess if you work somewhere with a policy of
| requiring you to use system packages, you're a little
| screwed, but that seems more of an organizational problem
| than a debian problem.
| Shish2k wrote:
| In this case I'm building software whose primary selling
| point is "trivial to install on practically any cheap-ass
| $1/mo shared web host, just unzip and FTP the files to
| your website folder" - which is the whole reason it's
| written in PHP in the first place.
|
| (The more I think about it, the more sad I am that it's
| 2021 and still no other language has come _close_ to
| PHP's low barrier to entry...)
| dreyfan wrote:
| PHP 8.x is very easy to install on debian by adding
| deb.sury.org to apt sources.
|
| https://deb.sury.org/
| martinp wrote:
| OpenJDK 17 is in Debian 11 as well [0]. A decision was made
| to include it before its official release since the release
| is so close (September). An updated package will be available
| when it's released.
|
| From the release notes [1]:
|
| Debian bullseye comes with an early access version of OpenJDK
| 17 (the next expected OpenJDK LTS version after OpenJDK 11),
| to avoid the rather tedious bootstrap process. The plan is
| for OpenJDK 17 to receive an update in bullseye to the final
| upstream release announced for October 2021, followed by
| security updates on a best effort basis, but users should not
| expect to see updates for every quarterly upstream security
| update.
|
| [0] https://packages.debian.org/source/testing/openjdk-17
|
| [1] https://www.debian.org/releases/bullseye/amd64/release-
| notes...
| eyelidlessness wrote:
| I read GP as considering ~4 years total and 2 years out of
| support a long time.
| seoaeu wrote:
| In other settings I can add a new feature to one of my
| dependencies and start using it within days or weeks. You're
| telling me you prefer having to wait _years_ to get any newly
| implemented feature?
| notyourday wrote:
| OS should not ship your language run time. OS is a giant
| cargo ship. It does not turn on a dime and it is not
| piloted by a "lets rewrite it in rust!" crew.
| robertlagrant wrote:
| Can you give an example?
| seoaeu wrote:
| Sure. In the Rust ecosystem, if you submit a pull request
| to a library it is very common for the maintainer to
| release a new version soon after. Even patches to the
| Rust compiler repository are released to stable in a
| matter of a few months (far less for the nightly channel
| that many people use)
|
| There's always workarounds and so forth, but it is really
| empowering to be able to have an impact over such a short
| timespan
| tomc1985 wrote:
| So add a couple of vendor repos and jump the versions queue
| like everyone else. I do this for all my main
| dependencies... postgres, ruby, etc
| koolba wrote:
| OpenJDK is still at 11 because that's the latest LTS version.
| Subsequent versions have significantly shorter upstream
| support lifetimes (IIRC, six months). Until another LTS is
| released, it'll continue to be 11.
| smarx007 wrote:
| Next LTS will be released on Sep 14, exactly in one month.
| AndyPa32 wrote:
| It means nothing that it will be released in a month.
| Because new software goes into unstable first, then is
| promoted to testing and only then to stable. So even if
| the next LTS release would have been released a month
| ago, it certainly wouldn't have made it into debian
| stable.
| vbezhenar wrote:
| Too bad, now wait for 2023.
| smarx007 wrote:
| I think it's rather Docker, Alpine, JDK 17 and jlink than
| waiting till 2023 :)
| cogman10 wrote:
| There's no such thing as "LTS" for the OpenJDK.
|
| LTS is strictly a JDK/JRE vendor concept. Oracle's
| distributions have 11 as an LTS and will have 17 as an LTS.
| That, however, only matters if you are paying oracle for
| support.
| ape4 wrote:
| This page https://adoptopenjdk.net/support.html has Java
| 8, 11 and 17 marked as LTS
| spockz wrote:
| Yes, that is LTS by the AdoptOpenJDK project. The GP was
| speaking of oracle LTS I presume.
| spockz wrote:
| Although technically true your statement misses a fact.
| Jdk 11 is still an LTS version for oracle which means
| that they are committed to improving that version with
| (security) fixes. These fixes will also be(come)
| available to the main OpenJDK distributions.
|
| Therefore, as a user of any JDK distribution you can
| depend a bit on the LTS versions, in addition that what
| your distribution promises.
| TavsiE9s wrote:
| > They don't break stuff.
|
| Unless they do due to their stance on licenses and remove mp3
| support from the lame package.
| 5e92cb50239222b wrote:
| You don't seem to know anything about the "web people" you're
| criticizing here. PHP skills learned two decades ago are
| still very relevant today. It's the Java of the web world.
| lexapro wrote:
| I don't understand the downvotes at all. Yes, PHP 8 is
| different from, let's say PHP 5, but that doesn't mean
| knowing PHP 5 doesn't help with writing good PHP 8. Same
| with Python 2 vs 3.
| roenxi wrote:
| What criticism?
| JasonFruit wrote:
| That's an excellent point: you described a difference,
| which is in fact real. Any perceived criticism is just
| that: a perception.
| bonzini wrote:
| Hmm no, not at all. My first job in 2002-2004 was using
| PHP4. I barely used classes (and if I did they were just my
| code, not from the library because I didn't need anything
| from PEAR) and used the original MySQL client API. Almost
| nothing of what I used back then would be useful today.
| PHP4 vs PHP8 is almost more different than Python 2 to
| Python 3.
| itwy wrote:
| Nonsense. +95% of Python 2 knowledge is transferable to
| Python 3. Same for PHP 4 to PHP 8.
| ptero wrote:
| I agree with your point, but your first word may get you
| many a downvote; I would remove the "nonsense" word to
| increase the penetration :).
| formerly_proven wrote:
| I've initially learned PHP4 when PHP3 was still used. Later
| I learned PHP 5 which iirc was the first version which had
| classes. I also learned Drupal 6 and then 7.
|
| Modern PHP code looks nothing like PHP code back then. Of
| course, the core syntax is mostly the same, but if you look
| at a framework like D6 or D7 _no one_ would do anything
| even remotely like this today. PHP security has completely
| changed since then as well.
| PaulDavisThe1st wrote:
| I thought that Java was the Java of the web world.
| stormbrew wrote:
| Java is the Java of the Java world.
| arendtio wrote:
| AFAIK, Debians conservatism was the reason why Ubuntu got so
| popular. So complaining that Debians packages are too old is
| somewhat of an old story itself ;-)
| flatiron wrote:
| I do the same but with Ubuntu. Arch Linux containers are
| awesome.
| geofft wrote:
| I'm an occasional Debian contributor and to be honest I think
| that's the right policy these days. It is effectively what we
| do at my employer.
|
| At my last employer, we ran Debian stable, and we told people
| to use versions of software (notably Python and Python
| packages) from the OS. One of my teammates was a Debian
| Developer, meaning he has full access to upload packages, and
| the two of us would package things up for the OS as we needed
| and get fixes into Debian as appropriate. In many cases we
| needed newer versions of packages than were appropriate for a
| stable release and (for whatever reason) weren't appropriate
| for backports either, so we ended up with a noticeable delta -
| it wasn't obviously less work than just building things
| ourselves independent of Debian. But because they were
| systemwide and you needed someone on the systems team to
| install those packages, what ended up happening is that my team
| found ourselves artificially in the middle of artificial
| development conflicts between other groups in the company,
| where one wanted a really old version and one wanted a really
| new version of the same package.
|
| At my current employer, we also run Debian stable, but our VCS
| repository ("monorepo," as people seem to call it these days)
| includes both internal and third-party code. Our third-party
| directory includes GCC, Python, a JDK, etc. (sometimes compiled
| from source, sometimes just pre-built binaries from the
| upstream). A particular revision / commit hash of our repo
| describes not just a particular version of our code, but a
| particular version of GCC and Python and Python libraries and
| so forth. Our deployment tool, in turn, bundles up all your
| runtime dependencies (like the Python interpreter) when you
| make a release. In effect, it's exactly the software release
| cycle properties you get from something like Docker.
|
| The practical effect is that upgrades are so much easier
| because they're decoupled. Upgrading the OS is hard enough -
| you have some script that's calling curl, and /usr/bin/curl is
| using the OS's version of OpenSSL, which has deprecated all the
| ciphers that some internal service that nobody wants to touch
| uses. Or whatever. Testing this is particularly hard if it
| affects your bare-metal OS, because you have a fairly slow
| process of upgrading/reimaging a specific machine, and then you
| run _all_ your code on the new OS, and you see if it works. If
| this change also includes upgrading your GCC and Python and JDK
| versions, it becomes extremely cumbersome. If you can deploy
| your language runtime, library, etc. upgrades separately (via
| Docker, via LXC, via something like our monorepo, whatever),
| then you 've decouple all of your potentially-breaking changes,
| and you can also revert changes for a single application. If
| the latest GCC mis-compiles some piece of software, it's a lot
| nicer, operationally, to say that this one application gets
| deployed to prod from an old branch until you figure it out
| than to prevent anyone from upgrading. And if a particular team
| insists on staying on an old version of some library, they
| don't hold up the rest of the company.
|
| And in turn that's why Debian has such a long freeze cycle and
| doesn't release the latest version of things. There's a whole
| lot of PHP software in Debian. All of it has to work with the
| exact same version of PHP (or you have to go to lengths to find
| every place that calls /usr/bin/php and stick a version number
| on it). If something is incompatible with PHP 8, the whole OS
| gets held back. That's exactly the policy you want for things
| that are unavoidably system-wide (init, bash, libc, PAM, etc.
| etc.), but you don't need that policy for application
| development.
| zozbot234 wrote:
| PHP 8.0 was not shipped in bullseye specifically because it
| could not be supported by Debian. A semi-official backport will
| most likely be available shortly after bullseye is released and
| testing/sid are reopened for new updates.
| GekkePrutser wrote:
| I'm kinda surprised they didn't run out of toy story
| characters yet. After all Ubuntu already ran out of letters
| georgyo wrote:
| Ubuntu releases twice a year. It only takes 13 years to
| outrun the English alphabet.
|
| Meanwhile, Debian from 1.0 released in 1996, 25 years, had
| only 11 releases. 16 if you count unique codenames.
| JPLeRouzic wrote:
| > _PHP 8.0 was not shipped in bullseye specifically because
| it could not be supported by Debian_.
|
| Please what do you mean by this sentence? What is the
| problem?
|
| (I use PHP 7.3 for my personal web site under Debian 10)
| progval wrote:
| There is a discussion on the topic here:
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811
|
| > The timing of this request makes me uneasy: php8.0 has
| been in Debian for less than a week, and we are a month
| away from the transition freeze.
|
| > My point of view after actually working on those issues
| is that there is a significant number of packages that are
| not working just fine with PHP 8.0, and require a fair
| amount of work before that. Some of them being security
| sensitive, so just working around visible issues may not be
| of the best interest of anyone...
|
| And by the time the maintainers decided to go with 8.0,
| they missed the deadline:
|
| > The transition freeze has started, so we'll not
| transition to php8.0 in bullseye.
| amyjess wrote:
| Honestly, I'd rather just use RHEL 8 (or a clone like Rocky
| or Alma) with EPEL. You have all the stability advantages,
| _plus_ an additional repository with bleeding-edge software
| that 's not in the official distro.
|
| (I worked at a RHEL shop for five years, and from my
| experience there I'd honestly rather not go back to having to
| deal with Debian-based distros ever again)
| 5e92cb50239222b wrote:
| Unlike previous PHP releases, 8.0 broke backwards compatibility
| pretty hard. Some old PHP projects that I have to support are
| completely unusable on 8.0. This gives me a few more years to
| port them, so I am all for it.
| miohtama wrote:
| The same happened with Python 3 and it took a decade to catch
| up. To be fairness, it was mostly about Unicode support and
| applications doing stupid stuff with strings.
| [deleted]
| je42 wrote:
| On the other end of the spectrum you have a distribution like
| Arch which gives you most recent releases, but then you also
| have to deal with breaking packages / package dependencies much
| more often.
|
| But i guess this comes down to "there is no free lunch".
| rubyist5eva wrote:
| Personally, I moved to CentOS from Debian (and then to
| AlmaLinux OS) because of DNF modules. You get multiple versions
| of different language runtimes and you can pick the ones you
| want to use - so I stick to the LTS versions. You aren't
| necessarily stuck to just _one_ packaged version of a language
| runtime now - and 10 years of support is lovely.
| zozbot234 wrote:
| Debian has the alternatives mechanism for that kind of thing.
| It works quite well.
| SkyMarshal wrote:
| Or just use the Debian Alternatives system to install PHP 8.0
| and make it the system default:
|
| https://wiki.debian.org/DebianAlternatives
|
| Once setup, one command can toggle between your version and the
| Debian repo version as the system default.
|
| DA is great, I used it for years on Ubuntu to override Debian's
| older default versions, or to install anything I wanted to
| build from source.
|
| I eventually migrated over to NixOS because, in a way, NixOS
| takes the concept of Debian Alternatives and applies it to the
| entire OS.
| robertlagrant wrote:
| This is why I like nvm/pyenv. Available versions should be
| managed via a tool, not by the system.
| [deleted]
| nickjj wrote:
| > ... build all my projects inside docker, using each
| language's most recent stable release
|
| This has been my personal policy for the last 6 years, it works
| well in practice.
|
| You get the best of both worlds. A rock solid system with the
| flexibility to use whatever programming runtime versions you
| want.
| user5994461 wrote:
| I don't think that works anymore with the speed that
| languages are moving and breaking these days.
|
| If you tried to use Python 3.9.0 for example (released
| November 2020), it had changes in the C bindings and broke
| many libraries (like numpy), which was not noticed until
| after the stable release.
|
| That took months to fix and I'm not even sure if all packages
| have been fixed as of today (9 months later).
| mistrial9 wrote:
| side note - this is huge news to me that Python 3.9 broke
| numpy ! very interesting to hear this
| nickjj wrote:
| > I don't think that works anymore with the speed that
| languages are moving and breaking these days.
|
| The beauty of this approach is you don't have to use the
| latest version if you don't want to, but the option is
| there if your app is compatible. You can still use Python
| 3.7.x or whatever you want. Docker has official Python
| images going way back.
| KronisLV wrote:
| Agreed.
|
| This also has the opposite effect - if there is any old or
| outdated component or piece of software that you still need
| to be running for unfortunate reasons, there's always the
| possibility of putting it in a container with all of the
| packages and other environment configuration that it
| requires.
|
| That way you don't have to risk compromising the entire
| system and don't even have to run VMs with old OS releases,
| while at the same time only need to expose the ports that the
| software uses, if even those at all. In my eyes, access to
| devices and such could still use a few improvements in Docker
| and other competing container runtimes, but for the most
| part, the technology is a lifesaver!
|
| While i do think that it's nice if the same packages are also
| available outside of containers, for the OS of your choice,
| which i'm sure will also be the case for latest versions of
| PHP and other software, even if done by a third party shortly
| after Debian's new release, that's sadly not always the case.
| In those situations, containers indeed seem like a good
| choice.
| e2le wrote:
| Given the inclusion of the Guix and Nix package managers into
| Debian stable, installing newer versions of software is an
| option if you need it. Perhaps even a better alternative to
| installing and using Docker.
|
| https://packages.debian.org/bullseye/guix
| pavon wrote:
| The only time it took 3 years between Debian stable releases
| was between Woody and Sarge, which happened over 15 years ago.
| All releases since have been on a 2 year cadence.
| heurisko wrote:
| On the other hand, I can think of many businesses who would be
| happy with such a conservative baseline.
| vbezhenar wrote:
| I think that the most significant feature in Debian 11 for me is
| wireguard. Debian is the only distribution that I could install
| on 256 MB VPS to use as a VPN.
| zargon wrote:
| Even 128 MB works great for a debian vpn.
| robertlagrant wrote:
| Blog posts please, from you both :-)
| bondant wrote:
| Is it released yet ? The download page still gives a download
| link to the version 10.10
| jhealy wrote:
| Not quite. The volunteers involved in the process are working
| on it, but there's probably still some hours to go.
|
| Some progress updates are being posted to twitter:
| https://twitter.com/debian
| gspr wrote:
| And here: https://micronews.debian.org/
| nvr219 wrote:
| Awesome! Grats on the release. Debian is my favorite Linux
| distribution and my go-to whenever I need to provision a server.
| [deleted]
| 404mm wrote:
| I know it may sound silly but I really like that they're still
| sticking with the Toy Story characters! Although I cannot say I
| even remember Bookworm (Debian 12).
| eth0up wrote:
| Probably futile, but... Please put wicd-curses back in the repos.
| Rumors of its deprecation have been greatly exaggerated. I find
| it continuing to work as well as ever while enduring the status
| as the only acceptable means of clean network management
| available in Linux.
|
| -Debian Testing user
|
| More practically, I beseech the compassionate and unglabrous-
| necked wizards of yore to impart their glorious mana to this dear
| and ailing friend, wicd. Please resurrect it. I beg.
| throwawaybutwhy wrote:
| Doesn't that require resurrecting py2 or porting it into python
| 3?
| gautamcgoel wrote:
| Debian is one of the software projects I admire the most. No
| glitz, no fuss; it's like the index fund of Linux distributions.
| TekMol wrote:
| I use Debian on all my servers and love it.
|
| I never managed to install it on the desktop though.
|
| How do you install Debian on a desktop these days?
|
| Usually, I downlod it, dd it onto a usb stick, boot from it and
| then Im stuck because it does not have my wifi drivers and I
| don't have a cable to connect my desktop to my router.
| abdullahkhalids wrote:
| You can grab the unofficial images as others say. Or simpler
| still, just usb tether your phone to your desktop and use that
| internet to install any necessary wifi drivers from the non-
| free repositories.
| Arkanosis wrote:
| That's pretty much the same for the desktop, except you are
| maybe more often in need of some non-free driver that you have
| to keep available at hand (eg. on another USB stick) for when
| the installer asks for it. I find it simpler to do the initial
| install with an ethernet cable, and only then install the Wi-Fi
| drivers (or the Nvidia proprietary driver) using the non-free
| repository.
|
| After installing your desktop environment of choice (eg. KDE),
| the user experience is very similar to that of Ubuntu, except a
| bit more barebone (or more minimal, or less bloated, however
| you say it) and more stable (in the Debian sense of stable; eg.
| you get Firefox ESR instead of the latest Firefox).
|
| I like the stability of it: there are very few updates, and
| even when there are, I've yet to see one that breaks something.
|
| That being said, I wouldn't use Debian on all my desktops:
| having few updates is not always desirable.
| TekMol wrote:
| I wouldn't use Debian on all my desktops: having few
| updates is not always desirable.
|
| "having few updates"?
| Arkanosis wrote:
| Well, yes; you don't get much to update with Debian,
| whereas using Arch, for example, you have many updates,
| very often. Sometimes having many updates is what you want
| (therefore use Arch) sometimes it's not (therefore use
| Debian).
| sillystuff wrote:
| If you run Debian stable (or oldstable), you only get back-
| ported bug fixes, and no new features-- the upstream
| versions of the packaged software are "frozen" before each
| new major Debian release _.
|
| So, you don't get a million updates caused by exactly
| tracking the upstream. You only get the updates necessary
| to address bugs.
|
| A huge upside of this is that you don't have to worry about
| breaking changes until a major version upgrade. E.g., some
| years ago upstream TCL changed its default from blocking to
| non-blocking I/O. I had to change nearly every TCL script I
| had to account for this change after dist-upgrading to the
| new Debian version. It was nice to not have a breaking
| change like this occur with just some random automated
| update.
|
| If you want Debian + rolling release, there is testing and
| unstable. But, packages in testing only get security
| patches when they trickle down-- there is no explicit
| security patching for testing. E.g., I wouldn't run a web
| browser or other security critical software from the
| testing release where it is exposed to the outside world.
| Probably safer to either run sid/unstable for a desktop, or
| careful use of pinning. For my own desktop, I've been
| running Bullseye testing, but pin Firefox back to Buster
| since it doesn't have any library conflicts.
|
| _ Firefox and Thunderbird are handled differently. These
| packages track upstream ESR versions in Debian "stable",
| and the version can change in the course of a stable
| release.
| ajot wrote:
| Personally, I use the non-free netinst CD. When I get to
| tasksel I only check "Standard system utilites". After
| rebooting (into a system without even X) I install, wifi and
| GPU drivers, microcode, "kde-plasma-desktop" and "plasma-nm".
| This way, I get a very minimal and lean KDE desktop, and after
| rebooting I install other programs as I see fit.
| em500 wrote:
| You could try the images which include non-free firmware:
| https://cdimage.debian.org/cdimage/unofficial/non-free/image...
| TekMol wrote:
| Thanks. What does "Unofficial images" mean?
|
| It sounds kinda dangerous to me.
| [deleted]
| sillystuff wrote:
| Debian will not ship non-free software in its main repos /
| official installers. The unofficial images are exactly
| that, created outside the rules of the project to avoid
| this prohibition. But, you don't have to trust them.
|
| You can download and place the non-free firmware files on a
| thumbdrive yourself, and the official installer can use
| them. It will stop and prompt you to insert the thumb drive
| if it is necessary to complete the installation.
|
| https://wiki.debian.org/Firmware
|
| If you e.g., netinstall over a wired ethernet connection,
| it is rarely a problem. But, all 802.11ac and above wifi
| chipsets require a non-free firmware. You can always add
| non-free to your sources.list and install nonfree firmware
| after installation for any devices other than those
| required for installation, i.e., your network adapter (and
| in maybe a super rare case for a desktop install, your disk
| controller).
| TekMol wrote:
| My first problem with this is the Firmware link you
| posted. I don't know what to download from it.
|
| My second is that I would like to boot from an USB drive
| first to try Debian 11 for a while without installing it.
| So there is no installer asking me to insert a thumb
| drive. I just dd the downloaded ISO to the USB drive.
| otterlicious wrote:
| The live images with firmware are here:
| https://cdimage.debian.org/cdimage/unofficial/non-
| free/image...
| zozbot234 wrote:
| These images are only "unofficial" due to the
| aforementioned non-free firmware; everything else in them
| is the same as in official images. Debian cannot guarantee
| that this firmware will be supported in any real sense,
| being proprietary; they're simply making it available for
| the user's convenience.
| viccuad wrote:
| Grab an image with non-free firmware and drivers included (for
| WiFi, GPU, etc):
| https://cdimage.debian.org/cdimage/unofficial/non-free/image...
|
| Put the image on a USB stick, boot from it into Live mode or
| start the installer, which is quite good.
| [deleted]
| marcodiego wrote:
| Years ago I'd be reluctant of using debian stable on my desktop
| because it mostly meant old packages. Now, with appimages, snaps
| and flatpaks I can finally have a rock-solid stable system
| combined just released new software.
|
| Debian are also very important events because it influences all
| of its descendants like ubuntu, armbian and raspbian.
| zibzab wrote:
| How well does system stuff work as snaps/flatpacks?
|
| (I.e. things like LXC and multipass)
| mrweasel wrote:
| I was testing out MicroK8s on Ubuntu, as a Snap. Regarding
| stability, I can't say, I didn't use it long enough. What
| really annoyed me is that it's confusing as hell. Files are
| no where near where you'd expect them to be. When things
| break and you need to go look for configuration files, you'll
| find that they are hidden deep down in /var. Snaps add a
| level of complexity I'm not comfortable with, while I gain
| very little.
|
| I am pleasantly surprised by how cleanly Snaps uninstall
| though.
| rlpb wrote:
| > Files are no where near where you'd expect them to be.
|
| > I am pleasantly surprised by how cleanly Snaps uninstall
| though.
|
| These two things are connected :)
| goodpoint wrote:
| Pretty bad, by design. It cannot really integrate with the
| OS, that's why OS packages exists.
| zibzab wrote:
| Hmm... that's not good, I really prefer LXC to docker
|
| (mainly because of better security and that I use Ubuntu
| and debian images instead of alpine anyway)
| goodpoint wrote:
| You can instead use dedicated directories, virtualenvs,
| chroots, firejail sandboxing, systemd nspawn containers.
|
| (In increasing order of effort)
| e2le wrote:
| Don't forget about the Guix/Nix package managers, available in
| the stable repositories.
|
| https://packages.debian.org/bullseye/guix
| _frkl wrote:
| That's similar to what I do, I just use the nix package manager
| for the stuff where I like to have newer versions. Best of both
| worlds...
| mgbmtl wrote:
| If using Gnome, using Sid is worth it. A lot of hate directed
| at Gnome is because of old versions, or distribution-specific
| hacks. I use the latest beta of Firefox for the same reason (as
| a webdev, worth it).
|
| Edit: the main risk with Sid is with proprietary software, such
| as Zoom. There's always a fix somewhere, but fiddling around
| can be distracting.
| cies wrote:
| I hate snap (no experience with flatpack). I have setup my
| Ubuntu to not use snap, and have snapd removed. I install
| Chrome from Debina Buster because that way it is not "snap
| packaged".
|
| Since I use nearly exclusively open source software I tend to
| trust it. I see the extra security benefits of snap and want
| that for sure, but all the trouble I had using it was simply
| not worth it for me.
|
| I'll come back in 10 years with snap and wayland have actually
| matured :)
| LeoPanthera wrote:
| If you're going to so much effort, why run Ubuntu in the
| first place?
| opan wrote:
| Wayland is great, imo, but I do not want any part of these
| alternative package formats. I'm much happier with the
| guix/nix approach.
| nickstinemates wrote:
| isn't guix/nix fairly alternative?
| nsizx wrote:
| I've been doing that since forever with Gentoo. Old kernel and
| desktop but recent applications. Or the other way around,
| really.
| sgarland wrote:
| Personally, I'd be fine with using Sid as a desktop as long as
| all data was backed up - but that should be a given for any OS.
|
| I'm a bit of a hypocrite, though, as I use a Mac for daily use.
| I do run Debian Stable for my servers, though! With Bullseye
| nearing completion, it looks like it's about time to bake some
| new VMs.
| ComputerGuru wrote:
| There's no real danger to your _data_ with Sid, just your
| productivity when your OS breaks.
| flatiron wrote:
| Never understood by people use Sid as a daily driver when
| there's arch.
| zozbot234 wrote:
| Unless you're using btrfs.
| yjftsjthsd-h wrote:
| Then sid isn't your problem...
| ComputerGuru wrote:
| Lol, I was going to make a btrfs quip and say I'd rather
| trust my data to Sid on xfs or jfs rather than an
| alternative stable distro that uses btrfs _cough_
| OpenSuSE _cough_.
| nerdponx wrote:
| Is it that bad? I have been using Tumbleweed as my
| desktop OS for several months, but I don't really use the
| Btrfs features at all.
| alyandon wrote:
| There are features of btrfs that are currently considered
| experimental/unsafe to use like their raid-5
| implementation.
|
| I personally use btrfs raid-1 setups and have survived
| actual device failures without data loss. However, I also
| perform regular backups so I'm not overly concerned about
| "eat my data" bugs in a filesystem either.
| matmatmatmat wrote:
| Plenty of people, including me, have never lost a single
| bit to btrfs.
|
| Now, is it super fast? (No.) Is it (or any other COW FS)
| the right choice for an SSD or database? (Probably not.)
| Is it the right choice for data that get read much more
| often than written and you'd like to be sure 10 years
| from now that you haven't lost any of it? (There's a
| pretty good argument to be made there, I think.)
| ComputerGuru wrote:
| I've lost* data with just RAID1 thanks to btrfs bugs
| post-1.0 that corrupted the entire metadata on both
| disks. There was no good place to get support nor any
| instructions on attempting reconstruction of corrupted
| metadata at the time and I haven't bothered with it
| since. Apparently I wasn't the only one that suffered
| such a loss and as I recall, it was blamed on OS-
| integrated CoW under certain circumstances but it was
| quite shortly after adopting it and not a particularly
| weird configuration so I swore it off and have been
| happily btrfs-free since.
|
| I should have known better since during my initial
| evaluation in search of a better llvm for Linux, I set up
| a root non-raid btrfs volume comprised of multiple
| dissimilar disks and lost all the data after an unsafe
| shutdown (a kernel panic that may have been caused by
| btrfs in the first place) even though all the disks were
| still functioning fine. I was an early adopter of ZFS -
| first under OpenSolaris, then under OpenIndiana, then
| (and now) under FreeBSD, so I thought I understand what
| "initial stable release" meant but it is clear that what
| ZFS devs consider to be stable and what btrfs devs
| consider to be stable are leagues apart.
|
| * I was able to use forensic tools and low-level fs-
| agnostic recovery methodologies to get some of the
| important stuff back, but the btrfs volumes were
| completely lost.
| fogihujy wrote:
| Argh, and I just deployed a Debian 10 system last week! Serves me
| right for not checking when the next release was due . :D
| scaryclam wrote:
| I have a new work laptop on the way. It was delayed, otherwise
| I'd have 10 on it now, so I'm pretty happy about this news :D
| wongarsu wrote:
| Me too. Well, still have three years to update before LTS runs
| out for Debian 10. The system probably won't survive that long
| anyways
| doubled112 wrote:
| Obviously YMMV, but the machines I've upgraded from 10 to 11
| have been running smoothly, and the upgrade was as simple as
| one could imagine.
|
| You know your systems better than I do though.
| viccuad wrote:
| Debian upgrades between major versions are supported and tested
| (contrary to other OSes). Reading the release notes of 11 is a
| good idea though :).
| user5994461 wrote:
| In theory it's supported, in practice you might lose the
| machine.
|
| Tried on 3 tests VM last month, nuked 1 out of them, failed
| somewhere mid process after removing half of the system
| packages. That machine never rebooted.
| goodpoint wrote:
| I've been upgrading company servers and personal desktops
| and laptops for 21+ years without getting an unbootable
| machine.
| blibble wrote:
| you've been pretty unlucky
|
| I must have upgraded at least 1000 times over 20 years and
| I've only had a machine become unbootable once
| lostmsu wrote:
| If Debian were Windows, that would be 3+ millions of
| users with unbootable PCs.
| blibble wrote:
| the machine it broken on was prehistoric, vs. the
| Microsoft approach for Windows 11 of not supporting
| machines less than 5 years old
|
| also: Debian and its derivitaves likely runs on more
| machines than Windows does
| user5994461 wrote:
| For the anecdote, it's possible to upgrade a windows
| machine in place from XP to Windows 7 to Windows 10.
|
| I've done it at home for multiple computers and it works.
| I don't do that sort of things at work however.
|
| There are obvious limitations on the hardware if you
| really want to go all the way from XP (32 bits), don't
| expect it to take SSD or high core modern CPU.
|
| P.S. Debian has order of magnitudes less desktops/servers
| than Windows. There's a tremendous amount of embedded
| devices on Debian but that's a completely different use
| case, if anything they never get an upgrade from the
| manufacturer.
| gspr wrote:
| Debian upgrades are notoriously smooth.
| YLYvYkHeB2NRNT wrote:
| > transitional dummy
|
| I take real offense to this politically incorrect descritptor
| used in the documentation.
| edwinyzh wrote:
| Great! And my free GUI admin panel will support it!
|
| https://sitemakertools.com/vps-bootstrapper (runs on workstation,
| only SSH is needed, no need to pre-install anything on the server
| side!)
| geokon wrote:
| I haven't used Debian in very long time. Have they converged on
| some alternative to the PPA?
|
| Like if I want the latest GCC or OpenJDK.. surely you don't
| download some AppImage, right?
| e2le wrote:
| If necessary, it's possible to install either the Guix or Nix
| package managers and then get the specific version of GCC you
| want that way.
|
| https://packages.debian.org/bullseye/guix
|
| Likely, this is more preferable than unofficial apt
| repositories or Docker.
| goodpoint wrote:
| Do not install OS components from unofficial sources.
|
| Regardless of OS or Linux distribution, there is no way to
| guarantee an unofficial package will not break your OS.
|
| You can instead use dedicated directories, virtualenvs,
| chroots, firejail sandboxing, systemd nspawn containers.
| tomc1985 wrote:
| Huh? Just add the vendor repos to APT and install through
| them... no need for anything exotic
| gspr wrote:
| The laying of some groundwork was recently discussed here:
| https://lists.debian.org/debian-devel/2021/07/msg00028.html
| still_grokking wrote:
| There is an unofficial (afik) effort to build something like
| AUR for Debian. It's quite new I think.
|
| https://mpr.hunterwittenborn.com/
|
| (HN discussion: https://news.ycombinator.com/item?id=27638107)
|
| But you don't need it for things like the latest GCC or OpenJDK
| as stuff like that is usually available form the Testing or
| Unstable Debian branches.
| zozbot234 wrote:
| If you're running Debian Stable, using the backports repo is
| generally preferable to installing packages from the testing
| or unstable channels. The latter will give you an unsupported
| configuration that might be broken to begin with, or break
| without warning in the future as stuff gets upgraded further.
| geokon wrote:
| I just checked and `openjdk-15-jdk` `openjdk-16-jdk` are
| only on sid/unstable - which `openjdk-17-jdk` is only on
| testing.
|
| So yeah, the only alternative is mixing version which is
| playing with fire.
|
| These seems like pretty basic distro problems, no? Since no
| one seems bothered I figured I was missing some obvious
| solution.
| zozbot234 wrote:
| The bullseye-backports repo is just being started, so
| these packages will most likely be available there
| sometime in the future.
| still_grokking wrote:
| Testing is (almost) Stable right now.
|
| They included a JDK17 pre-release so an upgrade though
| backports in a month will be easier than. (It's in the
| release notes linked here).
|
| Same reason why v15 and v16 are only in Unstable right
| now: They where not meant to be released for Debian 11,
| so removed from Testing.
|
| Usually Testing and Unstable are mostly in sync. Besides
| the packages in Unstable that are causing serous trouble
| of course.
|
| But right now Testing is mostly identical to the (still
| next) Stable Debian 11. So it makes no sense judging
| availability of packages in Testing right now until the
| release is out.
| lovasoa wrote:
| > A new open command is available as a convenience alias to xdg-
| open
|
| It's 2021 and we can finally open files from the terminal with
| "open". Hooray !
| [deleted]
| Tommah wrote:
| the year of the Linux terminal
| lazyweb wrote:
| Nice! Already upgraded most of my systems (around 10 VMs and 2-3
| HW systems) to Bullseye a few weeks ago without issues.
| lebrad wrote:
| We're about to experience a dreamy period of numerical software
| versioning where Debian, Windows, and macOS have all gone to
| eleven
| zibzab wrote:
| And android...
| dijit wrote:
| Doesn't that imply that they're all currently at version 10?
| vesinisa wrote:
| Latest stable macOS release is in the 11.x range. But it's
| likely that macOS 12 will be released before Windows 11, so
| GP's magical moment might not come to be.
| jtwaleson wrote:
| I think OP believes that 11 is more significant ;)
| https://en.wikipedia.org/wiki/Up_to_eleven
| HKH2 wrote:
| It implies that they're not all at 11 yet.
| zymhan wrote:
| Sure, but anyone can go up to 10. These go to 11.
| senorjazz wrote:
| :-D
| 0x0 wrote:
| Sad to see support for QNAP dropped in the kernel packages for
| armel, presumably because the vmlinuz kernel is 500kb too large
| for the default flash partition.
| zozbot234 wrote:
| This issue will also hit many mobile/embedded devices in the
| future where the kernel has to be flashed separately from the
| main installed system. (Debian does provide a flash-kernel
| workflow for this purpose.) The general solution is to use a
| separate bootloader (even Linux itself can be used as a
| bootloader via kexec), though this can involve a bit of wasted
| space.
| 0x0 wrote:
| Fingers crossed a solution could be found during the lifetime
| of debian11. The entire distro is ready for armel, such a
| shame that 500kb of missing flash partition space holds it
| back :-/
|
| I saw one of the bugreports had a message talking about using
| a different flash partition but it involved a lot of scary
| uboot hex memory addresses, which without a serial console
| could be a quick way to make a brick...
| ripdog wrote:
| I don't know anything specific about your situation, so I'm
| sorry for sticking my nose in here, but isn't this a case
| where you just need to compile your own kernel with a bare
| minimum of modules for your hardware? Surely that would
| save 500kb.
| 0x0 wrote:
| I'll have to look into it. I was hoping to ride the
| official marvell kernel binaries because building from
| custom sources on armel would be a great inconvenience.
| Also not sure I'll be able to find 500kb to cut that the
| debian people couldn't carve out. I would have thought
| these QNAP devices would make out a large percentage of
| the armel install base. Grateful that armel is still
| officially supported, just crazy that 500kb of missing
| default flash partitions is blocking access to the dozens
| of gigabytes of official debian armel goodness.
| puzzlingcaptcha wrote:
| Was it really just partition size? I vaguely remember Buster
| cutting support for armel below ARMv5T and the Kirkwood SoC was
| not quite making it.
| 0x0 wrote:
| The release notes say you can pin the debian10 kernel* and
| upgrade everything else. So my impression is 500kb of flash
| is the only blocker
|
| * and then you're on your own for security and compatibility
| issues
| acd wrote:
| I love Debian its very stable and well packaged. Big thanks to
| all Debian developers!
| whalesalad wrote:
| Woohoo! Congratulations to everyone involved on the release! I've
| tried almost every distribution under the sun and my heart always
| goes back to Debian. I've been running Bullseye for a few weeks
| (the RC's) and it has been a pleasure.
| uggedal wrote:
| Debian does not have release candidates. The installer does
| though.
| Tomte wrote:
| Off-topic, but I'd appreciate a hint: because I don't see a link
| to change language: what's the non-negotiated English URL?
| blendergeek wrote:
| English:
| https://www.debian.org/releases/bullseye/amd64/release-notes...
|
| The other language URLs are built like this:
| https://www.debian.org/releases/bullseye/amd64/release-
| notes/index.<ISO LANGUAGE CODE>.html
|
| So for French it would be:
|
| https://www.debian.org/releases/bullseye/amd64/release-notes...
|
| Just change the language code to your language and you should
| be set.
| forgotpwd16 wrote:
| https://www.debian.org/releases/bullseye/amd64/release-notes...
|
| Didn't even knew they had release notes in other languages.
___________________________________________________________________
(page generated 2021-08-14 23:00 UTC)