SomaFM is one of the sites I like to donate to when I can. I also use their Amazon affiliate link as an Amazon bookmark. Drone Zone has been my main background music when working for a couple of years now!
What would happen if the synchorized safe is open on two computers at the same time, they both add a new entry roughly at the same time?
I like the idea of this sync but I don't know how the internal implementation would handle this. Dropbox and Nextcloud both sync the files themselves, and in case of a conflict, they preserve both versions, and let you pick which one you'd like to use as the "canonical". It's a pain but at least the data is preserved.
I lost a lot of weight pretty quickly a few years ago. I gained some back, so I can't say my tip is "sustainable", but it worked very well at the time.
Most people agree that cutting calories is the key, and exercise helps. No magic. But one major fact that is too often overlooked is the mental aspect and how to persist with your diet until you have lost the weight you want.
My trick was to target a very specific date. Let's say 3 months from now, at 10:00 AM. I wrote down that date, say "June 10 at 10:00 am".
Then I swore to myself that, until that very specific date, I would not cheat. Not once. Ever. I would not eat any meal that is not specifically designed to cut calories. I would not eat any snacks other than those I had already selected as allowed.
Then I started the diet with that date in mind.
Having that immutable target date constantly in my mind helped me a lot in resisting temptations to eat more during the diet. As soon as a thought like "Yum, that would be so good!" popped into my brain, it was immediately stopped and rejected as unacceptable.
I don't like this kind of advice, only because it sets people up to fail. If your definition of "success" is not cheating, not once, ever, for 90 days, 99% of people will fail that. Half within the first couple weeks. And if you've failed your goal such that it's 100% unattainable now, what's the point of continuing at all? What's the point of setting another 90-day goal you'll also fail at?
This might help for people with a very small, specific goal in mind - lose n pounds or y% body fat by a certain event - and who are already pretty strong and consistent mentally. But if you are trying to lose weight to look better or not have a heart attack at 40, it's not a sustainable way to approach things. It's much more sustainable, and healthier, to focus on small habits you can add over time.
If you eat fast food four times a week and have five regular cokes a day, you're much better cutting that to three sodas a day and stopping there than you are eating kale salads and protein shakes for a couple weeks before going right back to where you were. And cutting a couple sodas a day is much easier to boot.
It's not sustainable. This is basically standard "diet" advice. Dieting is part of a fat lifestyle. You spend a few weeks or months being unhappy, waiting for some arbitrary time when you'll start eating and therefore being happy again.
To remain thin you need to adopt a thin lifestyle. There are no dates and no targets. You just find a lifestyle that works for you and live it.
I think my story is the same as many reluctant people: I had Covid, at the very beginning of the pandemic. It was like a flu but I lost my sense of smell for several months.
Having Covid made me question whether or not I should get the vaccine. My body did fight the real disease, why should I inject myself with something that only tries to mimic the real disease? I started to do some research...
My current conclusion is that my immune system is better than that of any vaccinated person who has not contracted the actual virus.
If serology testing can show you have immunity, I would support giving seropositive people the equivalent of a vaccine passport, if the epidemiologists confirm its good immunity. So, I can see a basis for your reasoning.
I would personally choose to still get vaccinated in your situation.
Because the certainty around the natural immunity is probably as questionable as the level of immunity from vaccination. Both are subject to epidemiological confirmation.
The potential harm of a re-infection or of infecting others is higher than the personal risk of being vaccinated.
I understand re-infection is something to think about. But infecting others is not an argument, as vaccinated persons can infect as much as unvacinnated ones. This is proven: https://www.youtube.com/watch?v=TKFWGvvlVLI
After a cursory check of the "frontpage" there... yeah, it doesn't seem very balanced. More like "r/The_Donald"-lite, with even some anti-vaxx stuff thrown in.
No moderation means it will be overrun with trolls and spammers. This is true of any discussion system. Once you grow beyond a certain point, typically a few dozen users or so moderation is necessary to avoid having the signal to noise ratio drop so low that all of the quality people leave.
- Fedora does its thing informed by but somewhat independently of RHEL.
- Red Hat chooses a Fedora release to be the base of RHEL, forks it, and starts working on it.
- This eventually becomes RHEL X.
- Red Hat then forks RHEL X to create the RHEL X.0 Beta and eventually the RHEL X.0 release. RHEL X keeps getting work done on it which eventually lead to another fork which creates RHEL X.1 Beta and RHEL X.1.
- After each RHEL X.y is released CentOS starts the process of rebuilding it from the sources and tracking upstream changes.
The new model puts CentOS where RHEL X is and so RHEL X.y are actually forks of CentOS.
This change matters a lot to you if you care a lot about the difference between the minor releases of RHEL because there won't be CentOS 7.1 CentOS 7.3 but just CentOS 7. If you just yum update on CentOS then you probably don't care since by default it will move you up minor versions. You have to try to stay on a specific minor version.
What's nice about this change is that anyone can peel off releases from CentOS the same way Red Hat will do to make RHEL and new features become available when they're ready instead of being batched.
There is a use-case for CentOS Stream, and if all Red Hat did was announced CentOS Stream and kept CentOS proper NO ONE would have any issue with that.
There is also a use case for a production fork of RHEL as well. That's now gone. People who migrated to CentOS 8 because they thought they were getting a decade of support - that's now gone.
So what are you arguing, that the second group somehow doesn't get it?
I can’t defend cutting support for CentOS 8. That’s super shitty and I don’t really understand the move.
The part I don’t think people really get is that if your goal was to have a fork of RHEL that was as close as possible to RHEL itself in absolute value that CentOS Stream is much better than CentOS is/was. CentOS always tracked far behind RHEL and now CentOS Stream will track closely in front of RHEL.
CentOS will be useless as a replacement for RHEL. Without the guarantee of binary compatibility, any CentOS Stream update may break your locally installed applications.
And I only recall CentOS significantly trailing RHEL at the major version updates (e.g. 6 and 7). Other updates seem pretty timely, and the major version lag doesn't leave me vulnerable.
I can see this being useful for developers who are building something that needs to be compatible with the next major release of RHEL, but I'm not sure who else it will be useful for.
I replied to you in another thread but nonetheless CentOS Stream isn't going to break your binary compatibility for the same reason that RHEL 7.3 doesn't break binary compatibility with RHEL 7.2. CentOS Stream is spiritually always the next minor release of RHEL.
Unless you're the kind of person who pinned to a specific minor version of CentOS (which isn't the default and not supported for very long) you can use CentOS Stream exactly the same as you currently are and it will be a strict improvement for you. Bugfixes, security updates, and new features will come to you before they're either batched for release in the next minor version of RHEL or back-ported to the current supported releases.
>bugfixes, security updates, and new features will come to you before they're either batched for release in the next minor version of RHEL or back-ported to the current supported releases.
Security fixes are not coming to CentOS Stream first. That's been in the announcement.
They do specifically mention that some fixes may come to RHEL first.
I'm sure they'll try not to break binary compatibility, but as it appears to be somewhat experimental and targeted to developers, breaking updates may occur. Isn't that the point of this distro -- so such testing can take place before updates are rolled into RHEL?
So, fine for a developer workstation, but I don't see how it can be stable enough to use in production.
RHEL requires expensive licenses. CentOS was RHEL without the RedHat branding and without the expensive licensing.
By design, there was a nearly complete overlap between RHEL and CentOS. By "repurposing" CentOS into a "rolling release", RedHat (IBM) has broken the overlap so CentOS (free licensing) no longer competes directly against RHEL (expensive licensing).
This is so misinformed it's funny. CentOS and RHEL will now be down to the compiler flags compatible since RHEL minor releases will now just be point-in-time forks of CentOS with security fixes and backports from, you guessed it, CentOS.
CentOS and RHEL will only be exactly the same at the moment when RHEL is a point-in-time fork of CentOS. As soon ad RHEL forks from CentOS, CentOS will roll forward and will no longer be exactly the same as RHEL.
Previously, CentOS was a rebuild of RHEL. In between RHEL releases, CentOS was exactly the same as RHEL. When RHEL had a release/fix/backpoint, CentOS trailed until it was rebuilt from the new RHEL source.
The "old" CentOS was exactly the same nearly always (nearly perfect overlap) and the "new" CentOS is exactly the same nearly never (almost no overlap).
You act like RHEL 7.1 is a fixed artifact — it’s constantly receiving updates, security patches, and backports. And CentOS always trails behind on those updates so it’s never exactly the same as RHEL either.
This change makes CentOS so much closer to RHEL that it’s weird that people are acting like the opposite is happening.
That's the whole point -- it's continually receiving updates that never break binary compatibility with existing apps/packages. For example, it's a safe target for vendors to target with binary packages, whereas CentOS stream won't be.
That's true of all RHEL major versions. You can safely target RHEL 6 or RHEL 7 without having to worry what minor version they might be running. The same will be true of CentOS Stream which is the upstream for the next minor release of RHEL. CentOS Stream isn't going to suddenly jump major versions.
If the current RHEL release is 7.x then you can think of CentOS Stream as 7.(x+1). You don't have to worry about it suddenly being 8.0. Fedora plays the role of the future RHEL 8.0.
I haven't touched PHP for a long time now. How is the Unicode support now? I remember having to use some special utilities to handle characters like "œ" properly.
You cannot use the "basic" string manipulation functions (strcmp, strlen, etc.) because these are not unicode-aware.
However, you have the multibyte string functions family that can operate in a wide range of encodings (including UTF-8 which is the default in any sane installation nowadays).
Handling those "correctly" with a string length function gets complicated in any language, as there isn't a 1-to-1 mapping between Unicode codepoints and visible glyphs.
