Don’t be so humble. You know, I started out exactly where you are, and to be honest, you know, my heart is still there. So I see you’re running Gnome. You know, I’m actually on KDE myself. I know this desktop environment is supposed to be better but you know what they say. Old habits they die hard. Yeah, I know what you’re thinking. I’m an executive. I mean why am I even running Linux? Again old habits. It’s gonna be fun working with you. I should join the rest of the group. Bonsoir, Elliot.
Tmux is a very helpful terminal multiplexer, meaning it can split your terminal into multiple panes. So, create two side by side panes, then one way of doing it is:
on the left, run your cmd | tee >(grep ‘denied’ > error.log)
on the right, run tail -f error.log
The tee process takes it’s standard in, and writes itbto both standard out, so you see all the lines, and the path it’s been given. The >(…) operator runs the grep in a subprocess, and returns the path to it’s standard input pipe, so grep receives every line, and writes the denied lines to a log file which you display with tail in the other pane.
Rather than using a file for error.log you could also use a named pipe in much the same way.
Run your rsync in one pane, with a filtered view in the second:
<span style="color:#323232;">tmux new 'rsync ...options... |& tee logview' ; split-window -h 'grep "denied" logview'
</span>
Replace …options… with your normal rsync command line.
That should give you a split view, with all the normal messages on the left, and only messages containing ‘denied’ on the right.
The |& makes sure we capture both stdout and stderr, tee then writes them to the fifo and displays them. split-window tells tmux to create a second pane, and display the output of grep.
I’m lucky enough to be in a company where Windows is banned by the CEO. Granted, there are 4 (I believe) exceptions, but the vast majority of employees have an Ubuntu workstation and everyone has a macbook. A bit of a shame this macbook thing, really. A 2 grand thin client to ssh into my desktop when working remotely :D
Actually, I always end up using ADB tools to get files or photos, you can get recursive files to get them all. I do it even with people that tries to get photos from their Windows machines, so I don’t think it’s a problem with Linux neither. This is the best way to get safely and correctly all your files.
sway with tabs (i usually dont use actual tiling)+4-5 workspaces
waybar for status display and on mobile also for menu access
rofi as the app launcher (i also plan to write a proper rofi menu for my phone for quick access to useful commands/config but it’s heavily wip)
i patched sway for push to talk because wayland spec doesnt support keybindings in a way required for push to talk for now
i also plan to patch it on the phone to completely forbid fullscreen apps (as they hide the menu which i use for workspace/window switching) and show the window bar on all windows (for example, firefox extension/downloads popups)
Elementary OS might be what you are looking for. It has their own DE (pantheon) that I think was one of the first to implement 1:1 gesture navigation. It still uses X if I’m not mistaken so you are probably going to be able to use the backlight correctly.
Looks interesting! Seems it pantheon is built on top of GNOME, so wouldn’t that make it a bit heavy for my 2GB RAM beater? Or is there really not that much difference between the different DEs with regard to resource usage?
Ohhhh, didn’t see the limited ram… maybe something with Xfce is the better option. With some customisation it looks very very good and is very very light
After some serious googling, it looks like gestures is a feature that really only exists in the “luxury” DEs. There is something called Touchegg and Touche that can add them to others, but I’m not far along enough to know if it will do what I want it to.
I just tried debian with Xfce, and it’s pretty fast, but I REALLY love using gestures! It makes my tiny screen feel way bigger.
Yeah, you don’t have to remove it (I didn’t when I tried this 10 years ago) but if you don’t you always have to hit ctrl+l when it boots, or it could get stuck looking for ChromeOS. The hardware is so old now, I don’t really care if I brick it. I’m just learning about linux by goofin.
At my current job, our department (DevOps), uses Linux (arch). A couple of devs too (Ubuntu), the rest use a mix of Macs and Windows. The Online versions of Office work just fine, there is Teams, Azure login and even Intune for Linux now.
At my previous job, most of the company used Windows, but the devs were using 90% Linux (Ubuntu), some of them with 2 machines (laptop and workstation with GPU, point cloud stuff). Ah, the good ole days of Ubuntu 16 and Nvidia drivers 🥲
The job before that, a very small company, mostly devs, we were using half Windows, half Linux (mint).
I mean, it still wants edge, which is okay for the online office stuff (SSO), but it’s pretty bare, when compared to Windows. No policies and stuff. Install it and forget it situation, mostly used for reporting. Ah, we also use defender for endpoint, on all 3 oses, which is rather decent.
This. I just started playing with Linux desktop in a VM and I’m not sure if it’s because it’s virtualized but I’ve had to kill plasma and relaunch or reboot several times because KDE is playing silly buggers.
You could try booting KDE neon Unstable in a VM on the same machine. If you can still reproduce it I’m sure the KDE devs would appreciate a bug report.
In fairness to KDE, yes, VMs absolutely can cause issues, and it’s likely you’d experience fewer of them if you ran it on real hardware.
But yeah, Plasma is relatively buggy. This is improving at a rapid rate, though - Plasma 4 and early Plasma 5 were straight up unusable, hence distros flocking to Gnome (KDE actually used to be the standard!)
The difference in stability between Plasma 5.27 and versions before about 5.16 is night and day. And Plasma 6 has been repeatedly pushed back so that it can be stable from the get-go.
I’ll check the version later. I wonder if Debian is using an old version and it’s worth enabling back ports for plasma. Ultimately I’m after stability, hence picking Debian.
Debian doesn’t ship bugfix releases of our software. If you want a stable experience in the actual meaning of the word instead of just something that doesn’t change, almost every other distro will be a better choice
Ya, but you’re overlaying all that stuff, codecs, nvidia, etc. ublue works out of the box and updates are quicker due to not having to re-overlay everything. It’s just less friction. Also it comes with automatic updates enabled which is really nice (and safe in an immutable, intrinsically rollbackable environment)
Overlaying isn’t bad. It’s kind of what we’ve done the past years anyway.
Does the speed of updates matter in any way? Unless it’s not days, there’s no reason for me to complain update the duration since everything is done in the background.
What’s the difference to the auto update in silverblue?
Ootb fedora doesn’t even have gnome extensions installed. We have to adjust our systems anyway
Personally, I’ve been enjoying uBlue over vanilla Fedora Atomic for what they offer in terms of system management.
To give you a better idea on what I mean; just a month ago an update to Podman caused breakage and people weren’t able to use their containers created with Distrobox/Toolbx^[1]^. Sure; a rollback is accomplished relatively easy and I’m sure some would even be able to fix it themselves. Regardless, every Fedora Atomic user that relied on Podman would have been interrupted to some capacity.
Which, of course, begs the following questions… Isn’t it very inefficient for everyone to fix this issue themselves? Wouldn’t it be easier if somehow Fedora forced some fix upon all of us so that just one entity is burdened instead of all of us? Heck, wouldn’t it be better if Fedora just withhold the update until it’s fixed? Is this perhaps some pipe dream that will never see the light of day? etc…
The interesting part, though, would be how I (a ‘uBlue-user’) didn’t even notice Podman was causing issues in the first place. “How?” you might ask, well… The uBlue devs noticed the issue, applied some magic so that I and many other uBlue users like me just went on with their day like they would otherwise; without being interrupted because Podman just had a bad update. (Did the supposed pipe dream actually already exist in some form or fashion?)
This is just the most recent example of this. But in the last year or so, out of the top of my head, there have been a few more times in which uBlue users didn’t even notice a thing while the others either had to rollback or fix their issues themselves. If you enjoy this interruption and/or are willing to deal with it for the sake of whatever, then please feel to continue to do so. However, I prefer to have a system I can rely on at all times and uBlue offers me just that while remaining very close to vanilla Fedora Atomic.
You won’t have fedoras signatures anymore.
It depends if you have the luxury to rely on them in the first place.
If setting up your workflow (or whatever) requires you to get to the nitty gritty of things and change those parts of the system that strictly speaking isn’t well supported by just rpm-ostree, then -for almost a year now- your best bet would have been to (instead) experiment with (what’s been referred in Fedora’s Wiki as) Ostree Native Containers.
Finally, let’s not forget that uBlue is even endorsed by Fedora (or at least by whoever maintains its documentation). Heck, even the inception of uBlue was due to an interaction between Jorge Castro (one of uBlue’s maintainers) and Colin Walters (one of the masterminds behind the whole rpm-ostree-ecosystem).
P.S. If I hadn’t made it clear, it’s totally fine to continue to rely on Fedora Atomic directly without any interventions from third parties for system management or whatsoever. I just wanted to elaborate why I, personally, prefer to use images provided by uBlue.
So you convinced me, and not being a novice, I didn’t read the install instructions and just went for it. It wrecked my dual boot efi partition. No worries, been there done that before, spent all morning trying to get the eufi shell and grub sorted out. After a few hours of failing, I’m like hey I planned for this, I’ve got a USB recovery for windows, and my actual data is all backed up via syncthing (thanks to this community). Why am I bothering with this nonsense.
Omg… Recovering windows takes foreeeeever. So then I’m reading the kenoite instructions and it calls out that dual booting doesn’t work, here is a suggested partition scheme… Ffs… Anyway for anyone that doesn’t want to waste an entire day on this, rtfm.
FWIW, I’ve put some effort into explaining how a dual boot of Windows 10 and Fedora Atomic (read Silverblue/Kinoite/Sericea etc) can be achieved. While it’s far from exhaustive, it should be fine as long as your specific installation of Fedora Atomic doesn’t require special attention (which happens sometimes with owners of an Nvidia GPU*). After Fedora Atomic is successfully installed, proceed with following the instructions found on the following parts of uBlue’s documentation: here, here and finally pick whichever uBlue image you’d like to install from this list; specific instructions are found directly underneath the text boxes for each individual image, but ensure you’re installing the one with the correct Fedora version (37/38/39/stable/latest etc (which are accessed via tabs)). If you can’t decide on which version you’d like to install, then just go for 39.
The Framework 13 inch model should be plenty, especially if you want to dev on the go. Much more lightweight and smaller, and you can connect it to external monitors if the screen size is not big enough. Also, you shouldn’t have issues running Linux on either laptops.
Instead of going for the 16 version, I would use the extra 900-1000 euros (that’s the amount I saw I could save between the two almost maxed-out models) to make a dedicated server or mini-cluster to run your workloads. Deploy Kubernetes or Proxmox on it, and you’ll also get some more practice on it outside work if you want to run stuff for your home lab. That is only if you don’t want to game on your laptop, but I’d still put that money aside to make a desktop.
Thanks for the advice! The 16 is probably as overkill as you say, but I’ve come to prefer a larger machine to work on.
I already have Proxmox installed on a secondhand mini-pc (one of those NUC / thin-client like office machines) and it’s been a great way to (re)learn a few things indeed!
I have a 1st Gen Framework and don’t recommend it.
Battery life in standby is TERRIBLE, we are talking 40% overnight (after optimizations) and very rarely the notebook wakes up randomly.
The build-quality is better than cheaper laptops, but definitely worse than my old Thinkpad. Although the keyboard is better than many consumer laptops, it feels a lot mushier than my Thinkpad’s. Several keys have lost their cover already and the display hinges are wobbly & feel cheap. I also got small spot with burn-in on the display. After 2 years the Framework looks worse than my 6-year-old X1 Yoga.
Linux support is okay, most things work out of the box. However, it’s far from perfect and absolutely not a First Class experience. For example, there is currently no way to get the most recent BIOS via Linux and apparently we are months away from a solution. In Fedora 39 Silverblue I experience very rare freezes (according to Arch Wiki this is due to Intel and not a Framework-exclusive problem, I still want to mention it).
My next laptop will be a new or used Thinkpad again.
Thanks for the heads-up. I’ve seen that the first gen had a few issues, I understand your frustration. I even saw a solution involving soldering a wire onto the motherboard? My hope is that they got better as they gained experience, and that hardware support on Linux will only imrove with time.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.