If any organization adopted the spec I would hope they would at least make it adopt a standard file extension like .oci so it would at least be more easily recognizable by IDEs, I have never liked having to put the use case as the extension like Dockerfile.dev
But I do like that docker and buildkit have been able to freely evolve the spec with things like advanced caching directives that work great in buildx
I just upgraded from a 7-year old XPS 15 - technically it was a Precision 5520 from when Dell still had a Developer Edition that would ship with Ubuntu but it was hands down the best Linux laptop I had. The things I loved about that one was:
- 45W TDP processor - none of the U series 15W slowness
- 4K screen that scaled to 1080P perfectly at 200% scaling - so X11 and XWayland apps still looked good. Also the screen quality was amazing
- Integrated Graphics - no messing around with NVIDIA drivers
I searched high and low for something similar but could not find anything on the market. So made some compromises and went with System76 Pangolin (pang15). Here are my notes on the machine
Pros:
- 45W TDP processor is fast
- They let you load it up with memory and disk for reasonable prices unlike most mainstream manufacturers
- 2nd M2 slot is nice for copying over old SSD
- They provide Windows Drivers in a GitHub repo
Cons:
- Battery life is pretty bad but I stay plugged in most of the time so not a huge issue for me
- Fans spin up pretty often
- USB-C charging only. There is an A/C Adapter barrel jack but they don't ship a charger and I can't find a suitable aftermarket charger. I worry about wear and tear on the USB-C port damaging it one day and that will be the end of the laptop effectively if I can't plug in.
- The screen needs around 133% fractional scaling which is not even an option. So I have to use a combination of 125% scaling and tweaks. XWayland apps look terrible so had to go through and force Wayland on all Electron apps and JetBrains and as you can probably guess there are random odd bugs
- Random issue (rarely) where I power it on and it does not start up, then I have to close the lid, hold the power button, etc before it starts up. Support told me to try booting with one memory stick but it's so hard to recreate I don't think I'll be messing around with it unless the issue starts cropping up more.
Now given all of the complaints, the increased speed over a 7-year old laptop is still nice so I am keeping it. Too bad Dell seemingly abandoned their Developer Edition program. The new XPS's force discrete graphics for good screen options and it's a roll of the dice whether WiFi or peripherals work properly with Linux. I've heard Lenovo has good Linux support for certain things but they also seem to be pushing discrete graphics for high screen resolutions.
Same boat, @6 year old Dell Precision 5540 here and am looking to upgrade.
Dell's latest offerings aren't particulaly inspiring, especially wrt pricing (absurdly expensive for what you get). Seems that PC laptop manufacturers have taken a page out of Apple's playbook and charge through the nose for memory and SSD upgrades.
To put in context, I paid $1,100 USD for this machine in October, 2019, and around another $200 for 2 X 512GB SSD and 32 GB RAM. So, $1,300 all-in. These days you're looking at least double the price.
And if you're going to blow $3K on a laptop, might as well go with a MBP; at least there you're getting high end hardware. Giving up Linux after 15 years is a bitter pill, hopefully Asahi Linux will come out with M3/M4 support in the next year -- in the meantime I'll migrate my current machine to a Fedora VM on the Mac.
> Laptops are especially problematic, with issues like Wi-Fi, sleep, and battery life.
100% true, but I love Linux as a daily driver for development. It is the same os+architecture as the servers I am deploying to! I have had to carefully select hardware to ensure things like WiFi work and that the screen resolution does not require fractional scaling. Mac is definitely superior hardware but I enjoy being able to perf test the app on its native OS and skip things like running VMs for docker.
Same! That's One less OS that I have to remember how it works!
I'm not sure I understand the whole tinkering thing. Whenever I tinker with my Linux, it's because I decided to try something tinkery, and usually mostly because I wanted to tinker.
Like trying out that fancy new tiling Wayland WM I heard about last week...
I feel like the main times Linux requires tinkering are:
1. You're trying to run it on hardware that isn't well-supported. This is a bummer, but you can't just expect any random machine (especially a laptop) to run Linux well. If you're buying a new computer and expect to run Linux on it, do your research beforehand and make sure all the hardware in it is supported.
2. You've picked a distro that isn't boring. I run Debian testing, and then Debian stable for the first six months or so after testing is promoted to stable. (Testing is pretty stable on its own, but then once the current testing release turns into the current stable release, testing gets flooded with lots of package updates that might not be so stable, so I wait.) For people who want something even more boring, they can stick with Debian stable. If you really need a brand-new version of something that stable doesn't have, it might be in backports, or available as a Snap or Flatpak (I'm not a fan of either of these, but they're options).
3. You use a desktop environment that isn't boring. I'm super super biased here[0], but Xfce is boring and doesn't change all that much. I've been using it for more than 20 years and it still looks and behaves very similarly today as it did when I first started using it.
If you use well-supported hardware, and run a distro and desktop environment that's boring, you will generally have very few issues with Linux and rarely (if ever) have to tinker with it.
[0] Full disclosure: I maintain a couple Xfce core components.
Two kinds of linux tinkering often get aliased and cause confusion in conversations.
The first kind is the enthusiast changing their init system bootloader and package manager and "neofetch/fastfetch" and WM and... every few weeks.
The second kind is the guy who uses xfce with a hidpi display who has to google and try various combinations of xrandr(augmented with xfwm zoom feature), GDK_SCALE, QT_SCALE_FACTOR, theme that supports hidpi in the titlebar, few icons in the status tray not scaling up(wpa_gui), do all that and find out that apps that draw directly with OpenGL don't respect these settings, dealing with multiple monitors, plugging in hdmi and then unplugging messing up the audio profile and randomly muting chromium browsers, deciding whether to use xf86-* Or modesetting or whatever the fix is to get rid of screen tearing. Bluetooth/wifi. On my laptop for example I had to disable usb autosuspend lest the right hand side USB-A port stop working.
If our threshold for qualifying well-supported hardware is "not even a little tinkering required" then we are left with vanishingly few laptops. For the vast vast majority of laptops, atleast the things I mentioned above are required. All in all, it amounted to couple of kernel parameters, a pipewire config file to stop random static noise in the bluetooth sink and then a few xfce setting menu tweaks (WM window scaling and display scaling). So not that dramatic, but it is still annoying to deal with.
The 2nd kind of tinkering is annoying, and is required regardless of distro/de/wm choice since it's a function of the layers below the de/wm, mostly the kernel itself.
I think that for your example of having problems with HiDPI you might have had in mind another desktop environment than XFCE.
I have been using XFCE for more than 10 years almost exclusively with multiple HiDPI monitors.
After Linux installation I never had to do anything else except of going to XFCE/Settings/Appearance and set a suitably high value for "Custom DPI Setting".
Besides that essential setting (which scales the fonts of all applications, except for a few Java programs written by morons), it may be desirable to set a more appropriate value in "Desktop/Icons/Icon size". Also in "Panel preferences" you may want to change the size of the taskbar and the size of its icons.
You may have to also choose a suitable desktop theme, but that is a thing that you may want to do after any installation, regardless of having HiDPI monitors.
I agree, in my limited experience the sub remains consistent even when changing the Google Workspace domain. So the email changes but sub remains the same. The issue seems to be clients matching on email/hd claim instead.
I wonder what action is causing the sub to change like the author suggests is happening.
At my current company, if an employee leave and come back, they'll keep the same OID in Entra but they'll get a new `sub` in Google workspace. We had to put in place a process to be able to use an internal tool that used the login with Google.
That's most likely dependant on how the IT department handled the deprovisioning/provisioning of users in our Google Workspace, I unfortunately don't have the details for that.
> I wonder what action is causing the sub to change like the author suggests is happening.
Indeed this would be very interesting.
This issue is also very similar to CVE-2024-25618.
What we did to mitigate this is the following:
- Federated login with OIDC
- Look for a user based on the sub claim
- If they are found: authenticate that user and optionally update their profile (email, name, ...) based on then new id claims.
- Else look for a user matching on the `email` claim and link the `sub` to that user
- If no user is found create a new one
> My boss came to see me. He told me that the team’s productivity was dangerously declining. That we should use artificial intelligence more effectively. That we risked being overtaken by competitors who, without a doubt, were using the very latest artificial intelligence.
I think this part is real. Developers who can use AI tooling to gain a multiple of productivity boost while still having the domain expertise to correct the parts that AI gets wrong will become much more desirable than ones who don’t.
But it’s not so much like the article states- AI is not itself the employee that managers love and their peers despise. The developer who can achieve extremely high and accurate velocity due to a combination of domain expertise and AI use will be the one that both managers and their peers love. And that organization will seek to hire more developers like that one.
Shortcut could be to create an array of sync.OnceValue, immediately invoking each element in a goroutine. Then iterate through the array and call each function again.
It blows my mind that a 6 digit code is considered a secure replacement for a password on these sites. Only a 1 in 1 million chance of brute forcing. Seems rather simple for a motivated actor with a botnet targeting a large list of accounts to have some degree of success.
Any competent IPS system would lock out a botnet, and it rotates, so you need to guess the right 6 digits within 90 seconds 30 plus 30 on both sides) until it's a different set of 6 digits.
https://docs.docker.com/build/buildkit/dockerfile-release-no...
If any organization adopted the spec I would hope they would at least make it adopt a standard file extension like .oci so it would at least be more easily recognizable by IDEs, I have never liked having to put the use case as the extension like Dockerfile.dev
But I do like that docker and buildkit have been able to freely evolve the spec with things like advanced caching directives that work great in buildx