Note that this is not advisable from a security standpoint (even for a desktop machine).
FWIW, I find keeping Debian testing or the latest Ubuntu release up to date relatively painless; security updates can be enabled automatically too.
Note that this is not advisable from a security standpoint (even for a desktop machine).
FWIW, I find keeping Debian testing or the latest Ubuntu release up to date relatively painless; security updates can be enabled automatically too.
Thank you. It’s important to mention that. I intended to, but forgot to. Someone who knows much about these things would likely tell you it is one of the most, if not the most, insecure ways to maintain an OS. You start with something that is more likely to have security flaws than does a stable distribution, and you may leave the flaws in place for a long time. Personally, I can’t be bothered. I’m reluctant to write the last statement, because it invites a litany, a call and response, that has already been recited in hundreds of threads. Litanies have their place, but it’s not the web.
For whatever reason, my gnome desktop invites me regularly to update things like the clock or the clipboard thingy, but never to install a security fix. If it were easier, I’d do it. Btw. the last time I finally caved in, it broke my panel and it took me a bit of time to fix it. More time than it does to click away the desktop notice a couple of times a day for a few months. (hmm… there probably is a way to ask the package manager for security updates in “testing”)
I have tried keeping testing or unstable up to date. Or only sometimes updating. Or updating piecemeal as I described. For now, I’m having good luck with “If it ain’t broke, don’t fix it”.
I should add one more warning. Updating piecemeal can put your installation into an inconsistent state.
(Well updating regularly can as well, but probably less often) By inconsistent, I mean there is no invocation of apt-get
that will subsequently allow apt-get -f install
to say everything is OK. You then have to do a bit of manual intervention.
Inviting one was not my intention; of course you do what you like with your own desktop.
FWIW, I have been updating Ubuntu daily for years, with negligible inconvenience.
Of course not! Your statement was succinct, correct, and neutral in tone. I forgot to mention it, and I’m glad you added it. The litany I’m talking about is a series of finger-wagging admonishments.
Anyway, this debian page addresses making only security updates.
This page has several suggestions, not all of which work. But in the post “A Few Tips On How To Manage Updates”, the last item, “install security updates only” works, but only if I include the flag “-y”.
apt-get -s dist-upgrade | grep "^Inst" |
grep -i securi | awk -F " " {'print $2'} |
xargs apt-get -y install
This left me with only 20 more packages to upgrade, so I just did it. Much ado about nothing.
God help me, so @ExpandingMan, what was the Manjaro-versus-X or 5-reasons-to-switch website that got you to switch?
I feel the tug.
When I first started using arch, I was using xfce desktop environment. At first, my favorite bar theme worked after switching from ubuntu. However, after gtk was updated, all that broke for me, since the themes dont support new gtk. So i had to find a new theme. At that time, i was very bothered by this, since it forced me out of what i liked, shortly after switching to arch. So at first, i added the relevant packages to a config file to prevent them from being updated. However, i was determined to stick with arch and get the latest updates. So i decided to make the switch to the new version. Eventually, some of my xfce toolbar icons started acting weird too. Since i dont care about how up to date they are, I added them to the list to prevent updates, while all my other packages are always the latest. I still have xfce installed (but now i only use i3, not xfce) and the only packages I dont update are those xfce tray icons and some jack-dbus packages that i need to be an older version.
Other than that, I dont have any trouble with having the very latest packages of everything
Also, one time, I noticed that one of the dependencies of Sage CAS (specifically libgap) was a newer version, so it broke some matrix group functionality that I wanted to use temporarily. However, i solved this by preventing that specific package from updating, and a few weeks later i updated it and all was fine again.
So I recommend moving to a rolling distro anyway, get all the latest packages. If you have any issues, add that package to the exception list, and you will be fine. You can remove it from the list and try updating again in future, since it is rolling distribution, it is likely that all the packages that depend on the outdated dependency will be resolved and updated much quicker than on other distros, so that you dont need to hold off on the update for a long time.
But as I said, 99.9% of the time, there are no issues with having the very latest. Actually, it is the opposite, everything is more likely to be stable in my opinion, because version incompatibilities are much more difficult to handle on debian based distros. It is only in rare cases that things break, and usually there is an RSS announcement to explain what you need to do to fix it on the arch homepage.
Try it out! It’s not as difficult as people say it is, but it does require some learning and spending some time on initial setup. Very worth it.
pacui
, which, in my opinion is something every distro absolutely should have.i3
+ neovim
+ qutebrowser
is awesome) it’s become more and more important to me to have access to up-to-date software through the package manager. Compiling all this stuff and keeping it up to date on other distros is a huge pain in the ass./etc/
and, more importantly, there (apparently) a higher probability that that one /etc
file is the only place you need to make that change, so you are much less likely to break thing by screwing around. The way everything is laid out is very logical. /bin
and /sbin
are just symlinks to /usr/bin
, /lib
and /lib64
are just symlinks to /usr/lib
. Perhaps most importantly, the Arch distros are actually well-documented. The Arch wiki is marvelous, and there’s a manjaro one as well.(In the above, when I said “other distros” I was mainly talking about debian, ubuntu and a little mint. I used to use Fedora quite extensively but it’s been a while. Any thing else, I’ve only dabbled in. I don’t dislike any of the ones I’ve mentioned. I still need to use Ubuntu and derivatives quite often and I don’t find that to be such a bad thing. I think the world of linux distros is actually pretty nice… except CentOS
… that’s horrible… if I ever want to know what linux was like in 1997 I’ll install CentOS
.)
I don’t recommend using Manjaro, just use Arch or Antergos (which is arch with an installer, if you’re lazy). The lag that Manjaro introduces into the package updates are a downside in my opinion.
It works for me, and I like a few of the other goodies that Manjaro offers, but I totally agree: if you are someone who finds that to be a downside, just go right ahead and use Arch or Antegros.
(I was going to “like” your response but it seemed too contradictory ).
oh god. I might go for it…
I have a dell thinkpad 13 with a 1920x1080 pixels screen. So I need to scale things manually in .Xresources
, which I think I managed to… Hopefully your bleeding-edge laptop is newer than that. I love the minimal feel of no desktop manager Debian with i3. And Debian is the first distro I settled on for a longer period of time.
Love your dotfiles, we use some similar tools! Hmmm…
Oh man, don’t get me started. If this is not the case in the Arch world, its a big mark in the pro
column.
I have a Dell XPS 13 with the higher resolution (3200x1800), everything works seamlessly in Ubunbu out of the box.
FWIW, I can second the recommendation for Manjaro – I’ve been using it for the last year or so on various machines and have been pretty happy with it so far (except for GPU support, but I think that’s just nVididas fault).
With regards to julia builds working nicely out-of-the-box, up-to-date packages and a generally sane philosophy, I can second arch. I haven’t tried manjaro.
But you need some pain tolerance for kernel / driver bugs. If your hardware is weird then you can expect to lose an afternoon tinkering until your machine works again, every couple of years.
Quite agree.
I have been using Ubuntu for a long time (mostly Xubuntu), until a couple months ago when I tried and started to use Manjaro with XFCE. Gnerally very good, but sometimes I ran into errors (xrdp, libGL, and recently Julia 1.0.1 which segfault), Then I came back to Xubuntu 18.04, no problem.
Manjaro comes pre-configured with i3?!? omg…
In principle it should work, up to date drivers are there and the configurator makes it very easy to select them and (from what I can tell) installs the properly. That said, I do have a laptop where Manjaro isn’t working for no apparent reason. If you have a similar experience I would be very interested to hear about it, as I’m still trying to get Manjaro working on that laptop to this day.
It could not have been the kernel version since you have the option to swap out the kernel all the way up to 4.19-rc1
. By default they use the latest LTS which is 4.14
which is newere than what is used on Ubuntu 18.04. That said, it seems there’s lots of evidence right here on this forum that there are lots of reasons to be wary on the graphics front. That’s disappointing and I hope the situation improves, but certainly anyone on a laptop with nvidia graphics should proceed very cautiously.
I recommend using Manjaro Architect. They use i3-gaps
. Their default i3 setup is quite nice, though I use my own.
While 4.14 was the latest LTS was 4.14, Vega graphics weren’t supported by the mainline kernel 4.15.
Maybe I’m wrong because Ubuntu was fine all the way to when it was on 4.04.
Maybe it automatically installed proprietary drivers during install, and didn’t need graphics then. (Fedora also only froze after the install, before updating the kernel). For a while, Ubuntu was the only distribution for which the open source ROCm drivers were supported.
I believe everything needed has been mainlined by either 4.17 or 4.18, but I still haven’t gotten around to trying to compile that stack myself. Ubuntu (and RHEL+CentOs) have binaries available.
Assuming it was a graphics issue, Manjaro ought to work as soon as the next LTS kernel is released.
I’m hoping this means that (on the AMD side, at least), the graphics situation is going to start looking a lot better on Linux.
Actually, arch repositories are already on 1.0.1
On an older laptop I had issues with the graphics with an nvidia card on arch linux, while it worked fine on xubuntu. However, on my newer laptop that I just got recently, I have no issues with nvidia/intel/bumblebee.
The bumblebee setup on arch linux was extremely easy, it worked easily without much/any configuration and lets me switch between the integrated graphics and the dedicated graphics seamlessly.
How well the graphics works depends on your specific hardware.
TO manjaro users i highly recommend doing a vanilla install of arch, it’s a one time setup, and you will know more about your config files and how your system is put together. Manjaro might be good as training wheels, but I highly recommend eventually doing a vanilla install of arch, it is truly worth it. Then you will have better understanding of why some thing works or doesn’t work, and how to make things nice. Installing it from scratch is not as hard as it sounds. First time is gonna be more tough, but once you know how it works, you will realize that it really makes a lot of sense how the install is setup for a clean arch install.
To really emphasize this (also and especially applies to Arch Linux):
However, one thing to nitpick about: Users need to be very careful when installing language-specific packages. For instance, pip and pacman can interfere with each other and may need manual intervention when the same package is installed with both manager. (In the end I solved this by simply installing all Python packages locally and I am very thankful that all Julia packages are only locally installed by default).
Unfortunately, I have started to run into some problems with bleeding edgeness and for now there are some things that I run with conda to avoid the next update-apocalypse.
But maybe NixOS (or only nix)is something that can fix this for me.
To get back to the original question: I use Arch Linux (which I find by far to be easier to install than Gentoo btw.) and XMonad (not that it matters ;)) and compiling Julia works for me without any problem.