Do you throw away all your cables when new features are added?
Only when you start to own a device that uses one of those new features?
Do you throw away all your cables when new features are added?
Only when you start to own a device that uses one of those new features?
Like me, that user wants to use ISO-8601 format for dates.
I didn’t see that option in the screenshot. Anyone know if that’s possible in this Beta?
Sorry again. I wrote this last comment (and this one, TBH) from my phone and “–iso=s” should have been “–iso-8601=s” . I’ve edited my comment and the command should now work (Making a backup of your grub.cfg containing the date, to the second, in the filename. I did that to hopefully avoid you running the same command again after trying some fixes and accidentally clobbering your backup).
Ahh, sorry.
For Fedora it looks like the default /etc/default/grub looks like this:
GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rhgb quiet" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true
( Taken from https://discussion.fedoraproject.org/t/how-to-regenerate-etc-default-grub/72677/9 )
If you’re using LVM / LUKS you may need additional kernel parameters, like resume=… for suspend to disk to work properly.
Please, before doing anything else, post the output of the following:
cat /proc/cmdline
And make a backup of your existing grub.cfg with:
sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg-backup-$(date --iso-8601=s)
Also, be sure that you have a LiveUSB on hand. You don’t want to be SOL if we break something and can’t boot again without fixing it first.
What version of Ubuntu are you using?
What is the output of the following command?:
dpkg -l | grep grub
If you urgently want your grub menu to default to the first entry that can be done first, but unless that’s needed I’d prefer to get to the root of the problem(s) and get a proper fix.
This should get you back to defaults:
sudo cp /usr/share/grub/default/grub /etc/default/grub && sudo update-grub
At some point you definitely did accidentally write to /etc/default/grub when you meant to write to /boot/grub/grub.cfg.
There’s no shame in that; Grub’s configuration process is very confusing and counter-intuitive.
Everybody who has used Linux long enough has stories of breaking their systems in sillier ways, and this didn’t even really break your system 🙂.
Pulseaudio used features of sound cards (most prominently the hardware read pointer) that ALSA/dmix alone never used.
ALSA/dmix could allow you to get the same power savings as pulseaudio if you set the hardware ring buffer size to, say, 2 seconds.
And that would be fine of you were just playing some music, but if you were also chatting and wanting to get prompt notification sounds they would always be delayed between 0 and 2 seconds depending on where the hardware read pointer happened to be when the system tried to play a notification sound.
ALSA/dmix could also allow you to set a tiny buffer size. Then your music would play, and your notification sounds would play promptly too. But if you were just playing music your CPU would never be able to go into the lower power sleep states because it would need to wake up every centisecond to service the tiny ring buffer.
That would kill your battery life.
Pulseaudio’s (terribly named) “glitch free” audio feature was the first solution for Linux that allowed you to get power savings and low-ish latency. Your mp3 player filled up the ring buffer once every two seconds, and if a notification came in pulseaudio would look at where the hardware read pointer was, take the contents of the buffer that was just about to be read, and mix the notification sound into it, writing the newly mixed sound data to the buffer just before the sound card read it.
So, from the user’s perspective nothing interesting seemed to happen, but they get better battery life and things like notifications or game sounds work like they expect them to.
ALSA drivers would commonly advertise support for accurately and precisely reporting the position of the hardware pointer, but since nothing actually used that info before, many drivers gave incorrect results, which would only cause problems when using pulseaudio.
My point is that focusing on length is missing the point.
That’s just the ad-hoc justification for their racist actions.
Most schools have absurd policies in writing that are never actually enforced, until someone decides it has suddenly become a-rule-so-important-we’ll-go-to-court-over-it .
Most of the time, when admin gets suddenly very focused on a rule like this, you’ll find there’s a marginalized student that they want to apply it to. But don’t bring race into this!
Just because you didn’t / don’t experience it doesn’t mean it’s uncommon.
This isn’t actually about the length of his hair.
It’s that Black natural / protective hair styles are seen by racists as being “disrespectful” and they even said why they have the policy.
Their list included many things, but only one of those was actually relevent here “respect for authority”.
Racist people and racist systems will always punish Blackness. This is just one specific example of a larger pattern.
Development of the Wayland specification and multiple Wayland compositors is funded by the X.org foundation, and done largely by current and former Xorg developers / maintainers.
So it still works!
I should have guessed.
Thank you 🤣
Bash scripts are rarely the best choice for large, complicated, programs or for software that requires complex data structures. (Git is very much in both categories)
In bash there are so many ways to accidentally shoot yourself in the foot that it’s absurd. That can lead to bizarre seeming behavior, which may break your script, or even lead to a security vulnerability.
There are things that make it a bit more manageable, like “[[]]” instead of “[]”, but a frustrating number of such things are bash specific and this is written for the subset that is POSIX shell, meaning you don’t even get those token niceties.
Where you generally “want” to use POSIX sh is for relatively simple scripts where the same file needs to run on Linux with bash, Linux with only BusyBox sh, OSX with zfs (and an outdated version of bash which will never be updated because Apple refuses to ship any GPLv3 software in MacOS).
This is not that, and so one would expect that:
The developer of this git implementation has poor / foolish judgement.
Shit will be buggy
Shit will be insecure
Shit will be a PITA to try to troubleshoot or fix
And shit will be slow, because bash is slow and this isn’t a job that you can just hand off all of the heavy lifting to grep / sed / awk*, because the data structures don’t lend themselves to that.
* You could write the entire program in awk, and maybe even end up with something almost as fast as a python implementation done in ⅒ the time, but that would be terrible in other ways.
Wubi will get you that Windows + Linux in the same partition achievement.
Multiple school officials in the U.S. have asked children to pee in front of them to prove that they’re “actually a boy”.
One principle literally kicked in the door of a highschool bathroom stall that a trans kid was actively using (to fucking pee / poop).
Genital inspections have been asked for (I hope not actually done) in children’s sports competitions.
This is really happening, and transphobic rhetoric is driving it.
Every woman friend I have would feel much safer being in a bathroom with a trans woman than with a trasphobe; Especially the butch lesbians.
She works in “criminal justice” for the U.S. military.
You can be pedantic about the ‘C’ in ACAB applying, but the Bastard bit inescapably applies.
No.
This is a vulnerability which allows bypassing secure boot protections. You have already manually bypassed those protections by disabling secure boot.
A concrete example of this is doctors and hospitals creating guidelines about how to triage care when ICUs were/are full because of unmitigated spread of COVID.
It is definitely an “interesting” phylisophical question to ask:
“If a long term ventilator user comes into the ICU, with the ventilator they own and brought from home, and they are less likely to survive than an otherwise healthy young man who needs a respirator due to COVID infection, is the morally best choice to steal the disabled person’s ventilator (killing them) and use it to save the young man’s life?”
The policy question that should be asked instead, and never really ways, is “How do we make sure that we never get to the point where we have so many people in the ICU from a preventable disease that we run out of respirators and need to start choosing who to let die?”
This is not just a hypothetical question:
Disabled people continue to plead with us for the bare minimum, like requiring doctors who work with immunocompromised patients to wear N95 respirators while treating those patients.
We continue to chose to stack more people on both sets of tracks instead.
Please be sure to check that the smart switches you have space heaters plugged into are rated for that many amps.
I tried to solve these cross-distro compatibility problems in a generic way with this “standard”, more years ago than I’d like to think about:
https://www.supergrubdisk.org/wiki/Loopback.cfg
If someone wants to come up with a bootloader agnostic solution rather than one tied to grub, like an extension to Bootloader spec , https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ , I’d be happy to evangelize it and add support to grub for using it.
I’m not aware of any other bootloader that supports reading a config file that exists within an iso though, and secure boot support may add additional complications.
Bottom line:
I feel like we could relatively easily get to a point where every Live iso that actually supports loop booting can just be added, as a file, to your USB drive (from Windows, or your android phone even) and be detected at boot in a nice little menu, no editing of config files needed.
I don’t have the time or spoons to get the Linux community there alone, but if people are interested in helping I’m more than happy to pick this up again.
(Note: Please don’t blindly suggest “Just chain load the iso!” Things aren’t that easy, unfortunately).