You lose information when DST kicks in - which is not great. It is trivial to convert to any timezone so there is little point in logging in anything but UTC and keeps everything consistent. Especially when comparing dates from servers in different timezones.
So, if you just use the system API, then this means logging with syslog(3). Learn how to use it.
This is old advice. These days just log to stdout, no need for your process to understand syslog, systemd, containers and modern systems just capture stdout and forward that where it needs to do. Then all applications can be simple and it us up to the system to handle them in a consistent way.
NOTICE level: this will certainly be the level at which the program will run when in production
I have never see anyone use this log level ever. Most use or default to Info or Warn. Even the author later says
I run my server code at level INFO usually, but my desktop programs run at level DEBUG.
If your message uses a special charset or even UTF-8, it might not render correctly at the end, but worst it could be corrupted in transit and become unreadable.
I don’t know if this is true anymore. UTF-8 is ubiquitous these days and I would be surprised if any logging system could not handle it, or at least any modern one. I am very tempted to start adding some emoji to my logs to find out though.
User 54543 successfully registered e-mail [email protected]
Now that is a big no no. Never ever log PII data if you don’t want a world of hurt later on.
2013-01-12 17:49:37,656 [T1] INFO c.d.g.UserRequest User plays {‘user’:1334563, ‘card’:‘4 of spade’, ‘game’:23425656}
I do not like that at all. The message should not contain json. Most logging libraries let you add context in a consistent way and can output the whole log line in Json. Having escaped json in json because you decided to add json manually is a pain, just use the tools you are given properly.
Add timestamps either in UTC or local time plus offset
Never log in local time. DST fucks shit up when you do that. Use UTC for everything and convert when displayed if needed, but always store dates in UTC.
Think of Your Audience
Very much this. I have seen far too many error message that give fuck all context to the problem and require diving through source code to figure out the hell went wrong. Think about how logs will be read without the context of the source code at hand.
It is a digital signage display (ie in store ads, menus, displays etc) - not meant for desktop use.
I think their though process is more along the line of:
Hey, Microsoft is getting all the bad attention ATM, let’s see how much shit we can sneak in while people are distracted.
Except desktop environments - they are far from a simple loosely collection of simple stuff. They coordinate your whole desktop experience. Apps need to talk to them a lot and often in ways specific to a single DE. Theming applications is done differently for every toolkit there is, startup applications (before systemd) is configured differently, global shortcuts are configured differently by each one… If anything it is something you interact with far more than systemd and has far more inconsistencies between each one. Yet few people complain about this as much as they complain about systemd.
Systemd is a giant mess of weirdly interdependent things that used to be simple things.
They used to be simple things back when hardware and the way we use computers were much simpler. Nowadays hardware and computers are much more dynamic and hotplugable and handle a lot more state that needs to persist and be kept track of. https://www.youtube.com/watch?v=o_AIw9bGogo is a great talk on the subject and talks about why systemd does what it does.
What standards? The old init systems were a loose collection of shell scripts that were wildly different on every distro. Other tools like sudo also broke the established standards of the time, before it you had to login as root with the root password.
Even gnome and KDE have their own themeing standards as well as other ways of doing things. Even network manager is its own standard not following things that came before it. Then there are flatpack, snaps and app images. Not to mention deb vs rpm vs pacman vs nix package formats. Loads of things in Linux userland have broken or evolved the standards of oldern times.
Systemd does a lot of things that could probably be separate projects,
I dont get the hate for this - Linux is full of projects that do the same thing: coreutils, busybox, kde, gnome, different office suites, even the kernel itself. It is very common for different related projects to be maintained together under the same project/branding with various different levels of integration between them. But people really seem to only hate on systemd for this…
Yup, and that is because people only ever lean DRY coding by its name. It is never really what it originally meant, when to use it and more importantly when not to use it. So loads of people apply it religiously and over use it. This is true of all the popular catchy named methodologies/principals etc.
Yup, this is part of what’s lead me to advocate for SRP (the single responsibility principle).
Even that gets overused and abused. My big problem with it is what is a single responsibility. It is poorly defined and leads to people thinking that the smallest possible thing is one responsibility. But when people think like that they create thousands of one to three line functions which just ends up losing the what the program is trying to do. Following logic through deeply nested function calls IMO is just as bad if not worst than having everything in a single function.
There is a nice middle ground where SRP makes sense but like all patterns they never talk about where that line is. Overuse of any pattern, methodology or principle is a bad thing and it is very easy to do if you don’t think about what it is trying to achieve and when applying it no longer fits that goal.
Basically, everything in moderation and never lean on a single thing.
Refactoring should not be a separate task that a boss can deny. You need to do feature X, feature X benefits from reworking some abstraction a bit, then you rework that abstraction before starting on feature X. And then maybe refactor a bit more after feature X now you know what it looks like. None of that should take substantially longer, and saves vast amounts of time later on if you don’t include it as part of the feature work.
You can occasionally squeeze in a feature without reworking things first if time for something is tight, but you will run into problems if you do this too often and start thinking refactoring is a separate task to feature work.
“Best practices” might help you to avoid writing worse code.
TBH I am not sure about this. I have seen many “Best practices” make code worst not better. Not because the rules themselves are bad but people take them as religious gospel and apply them to every situation in hopes of making their code better without actually looking at if it is making their code better.
For instance I see this a lot in DRY code. While the rules themselves are useful to know and apply they are too easily over applied removing any benefit they originally gave and result in overly abstract code. The number of times I have added duplication back into code to remove a layer of abstraction that was not working only to maybe reapply it in a different way, often keeping some duplication.
Suddenly requirements change and now it’s bad code.
This only leads to bad code when people get to afraid to refactor things in light of the new requirements.Which sadly happens far to often. People seem to like to keep what was there already and follow existing patterns even well after they are no longer suitable. I have made quite a lot of bad code better by just ripping out the old patterns and putting back something that better fits the current requirements - quite often in code I have written before and others have added to over time.
I don’t know, it does have official in the name tag. People would not lie about that. Right?
A system us bloated when I feel it is bloated. It is highly subjective and there is no real line to cross. It is just more of a sliding scale, at one end there is no code on your system that you never use and at the other there is nothing on it that you ever want to use.
The former can likely on be reached on small microcontrollers where you have written everything exactly how you want it, and you would never even consider using the latter.
Realistically every system has things younever use, even the kernel has modules you will never load. And every non tiny program has features you never use. All of that is technically bloat but each instance I don’t think makes your system or even an application feel bloated.
So really the question is when does the bloat bother you or get in your way. If you are trying to install an OS on a tiny embedded device where space is a premiumthenn you are going to draw that line at a different point to on the latest desktop with multi terabytes of storages and oodles of ram.
Anyone that claims there system has no bloat is technically lying to themselves. But if it makes them happy who cares? If your system has every package installed and it does not bother you at all thenitt does not matter at all.
So, basically every system then?
Yeah, I really hate having to install a different language interpreter when working another one. Basically makes me very unlikely to bother with the tool in the first place.
It sounds like you may just want to wait a month or at least the end of this month. Looks like they are working hard on getting to the first alpha in 24.04 according to their post in January
The goal for the COSMIC DE alpha is to feel like a complete product, albeit with features still to come. With a more stable alpha, we can better collect feedback on usability and focus on completing the Settings panels. From here, we can work towards an eventual 24.04 release over the summer.
Though on their latest post on the 17th of April they only mentioned PopOS! 24.04 being released and did not really say much about maturing the prealpha to alpha at all. However they did mention their CEO is going to show off COSMIC DE at LinuxFest Northwest on the 27th
A reminder that System76 CEO Carl Richell and UX Architect Maria Komarova will be at LinuxFest Northwest this year to showcase COSMIC DE.
Might be worth waiting at least until then to see if anything gets announced or timelines get updated. Still only alpha though so may or may not be suitable for a full replacement yet, even if we are getting closer.
From looking into this s a few days ago it looked like things were packaged in the unstable channel so you can install them. But from what I read there is no way to configured it via nix configs so you would manually have to write them for now.
https://nixos.wiki/wiki/COSMIC
There is also this flake which should give some configuration for it but it mentions it might not be dully working yet and I have not yet actually tried it.
I don’t expect things to change much in this regard though until they start releasing some more stable versions of cosmic which is still in a prealpha state.
Never seen anyone change it for the mouse, but I think for a joystick and especially gyro it is more common to have them different. Same basic principal applies to all three inputs though.
In first person games the distance you need to move horizontally is often far more then the distance you need to move vertically, quite often only needing to look up/down a small amount. So you can get better accuracy in the vertical direction by turning down the sensitivity without sacrificing the ability to move quickly up and down. But in the horizontal direction being able to move quickly is generally more important than better accuracy.
Not sure how important the difference is for the mouse though, likely why people don’t use it. But it is an easy setting to split up for the developers so why not give players control over it and set it however they like? Would be nice if you could lock them together, but that is a little more complex and requires more thought to do. And I don’t see game devs giving that much thought about the minor user experience improvements in their games settings when they have a load of gameplay still to worry about.
How do we know these are the AI chatbots instructions and not just instructions it made up? They make things up all the time, why do we trust it in this instance?
Your battery drains more the more you activity use the device. Shocking…
If it is your phone just uninstall those apps, then you cannot use them. If the devices main point is those apps like gaming on the switch what do you expect? I think the only real problem here is the switch’s lack of customizability so you have no trade off between game quality and battery life like you can on something like the steam deck.