BorgDrone @ BorgDrone @lemmy.one

Posts

1

Comments

970

Joined

2 yr. ago

We could also reduce our population and keep eating meet and doing other things that make life enjoyable. Besides, who wants to live on a planet that crowded?

The only thing that will really fix the issue is if we stop breeding like rabbits. It doesn’t matter if we reduce the ecological footprint of individuals if we keep growing the population.

It’s the same in the Netherlands, but the notice period for the employer is always double that of the employee.

It depends a bit on your viewing distance. With 65” you should probably at about 1 to 1.5 meters from the screen.

Sure, but back then the whole issue didn’t get that much attention to begin with.

Maybe she had shit to say but no one would care. There are plenty of nobodies with similarly crappy opinions but no one pays them any attention.

Maybe because your TV is too small?

4k is not about a sharper picture, neither was 1080p. The sharpness was already good enough. The point of the increase in resolution is larger TVs at the same sharpness. Back when I had an SD TV it was 576p on a 28” screen. When I moved on to 1080p I got a 50” TV. Notice how the size and the resolution increase are in the same ballpark. Now with 2160p I have a 77” TV, so there is still a little wiggle room. I could get to 100” at 4k before I would have to consider 8k.

TVs got larger over the years, and that was made possible by the increase in resolution. There is still some room for growth in 4k.

You assume incorrectly.

The way it works on macOS is that you select the ‘looks like’ resolution to determine the size. For example if you have a 4k monitor you can set a ‘looks like’ resolution of 2560x1440. Internally it always renders at 2x, so in this case it will render to 5120x2880. That image is then scaled down to the actual display resolution, e.g. 3480x2160. It’s basically supersampling.

Meanwhile, macOS has been handling high-dpi displays with zero issues since 2012.

When you have more experinece in programming in more languages, you'll find that in a lot of modern languages an int is always 32 bit and a long is 64 bits

Once you gain some more experience you will realize that ‘a lot of’ is not good enough. Some languages do, some don’t. If you define a format, you don’t say ‘int’, you say something like “int32 in network byte order” (a.k.a. big endian).

Interesting that you were boldly claiming that experts use a dd-MM-yyyy format

Stop being willfully ignorant. I’ll repeat it once more: my claim is that you should store your dates as individual components, not as a the time since an epoch. I don’t care how those components are stored as long as it’s clearly specced.

Does your janky string format of “18-03-2024” suddenly has to become aware of the timezone

No, there is no timezone, and that is the entire point. In the majority of cases you just want to store the local date. The point is that a local date or time is not necessarily a fixed point in time. If I have drinks at 18:00 every Friday, that doesn't change when we switch to or from DST, it's still 18:00 in local time. I don't need a timezone, I know what timezone I live in.

Now, in cases where timezones do matter, for example if you have a Zoom meeting with someone from another country, you can store as local time + timezone. But this is still very different from storing a Unix timestamp. This meeting will be at a specific time in a specific timezone, and the exact moment in time will adjust when changes are made to that timezone. Again, a Unix timestamp does not allow for this, as it's always UTC.

I assure you that 1710720000 will translate to the same janky “18-03-2024” format you’re using every single time unless you deliberately mess with timezones in code

No, it doesn't. You can't convert it to any date unless you "mess with timezones", because 1710720000 is a specific moment in time and you have to provide a timezone when converting it to a date. You are mistaking the fact that some systems implicitly use UTC when converting for some sort of of universal standard, because it's not.

Run the following Swift code:

    
let d = Date(timeIntervalSince1970: 1710720000)
print(d.formatted(date: .complete, time: .omitted))


  

You'll get a different date depending on your location.

If your code will break because someone has different OS settings than yours, you are writing bad code.

Yes, and your bad code will break simply because you are abusing a datatype for something beyond it's intended use. If you want to store an absolute point in time, by all means use a Unix timestamp, but if you want to store a local time you should never use it because it's not mean for that and it doesn't encode the information needed to represent a local time.

Even this would be better than a string:

struct { int year byte month byte day }

Yes that's fine. I'm not arguing that you should store it as a string, I'm arguing that you should store it as individual components, in whatever format, instead of seconds since the epoch. As long as the format is well specced it doesn't really matter. Strings are used all the time for representing dates by the way. For example, ASN.1, which is used everywhere, stores dates and time as strings and it's perfectly fine as the format is specified unambigiously.

Six bytes as opposed to 10

In what archaic system are int's still 4 bytes? Int is 64-bits, or 8 bytes, on any modern machine. If I read your format on a 64-bit machine, it'll break. Also is that int little or big endian? You code still breaks if you spec an int32 and you store your date on an x86 machine (little endian) and I read it on a big-endian machine. You know what's not ambiguous ? "This time is stored as an ISO8601 string".

You also don’t store dates in a string that you’ll have to parse later

Depends. If the format is clearly defined, then there's no problem. Or could use a binary format. The point is that you store day/month/year separately, instead of a Unix timestamp.

And you understand that you could have a date in unix time and leave the time to be midnight, right?

No, you can't.

First of all, midnight in what timezone? A timestamp is a specific instant in time, but dates are not, the specific moment that marks the beginning of a date depends on the timezone.

Say you store the date as midnight in your local timezone. Then your timezone changes, and all your stored dates are incorrect. And before you claim timezones rarely change, they change all the time. Even storing it as the date in UTC can cause problems.

You use timestamps for specific instances in time, but never for storing things that are in local time. Even if you think you are storing a specific instant it, time, you aren't. Say you make an appointment in your agenda at 14:00 local time, you store this as a Unix timestamp. It's a specific instant in time, right? No, it's not. If the time zone changes so, for example, DST goes into effect at a different time, your appointment could suddenly be an hour off, because that appointment was not supposed to be at that instant in time, it was supposed to be at 14:00 in the local timezone, so if the timezone changes the absolute point in time of that appointment changes with it.

When you think about it storing a date with 6 bytes would take more space than using Unix time which would give both time and date in four bytes. Y2K38 is the real problem. Y2K was a problem with software written by poor devs that were trying to save disk space by actually using more disk space than needed.

This comes to mind:

You don’t store dates as Unix time. Unix timestamps indicate a specific point in time. Dates are not a specific point in time.

Without drilling down into what that means, the limit of that data storage type will be a count of 4,294,967,296.

A little nitpick: the count at that time will be 2,147,483,647. time_t is usually a signed integer.

I was looking for a new printer and I also wanted to print photos. Problem with inkjets is that you have to use them regularly or the ink dries out so that was no option either.

I eventually settled on a black and white laserprinter, which is cheap to buy and run (a new 3000 page toner is like €40) and a Canon Selphy CP1500 for photos, which uses dye sublimation so no issues with ink drying out. It only prints 15x10 photos which covers the majority of my needs, for anything larger I want to use a good photo printing service anyway.

You could also do what they do in the Android world, let the phone run like crap all the time, then it won’t need to slow down because it was slow from day one.

You are saying I have the choice between a shitty choice and a shitty choice that breaks.

Until you invent a better battery tech those are the only options we have. Let me know when you filed your patent.

Which is weird because I'm not in a city and live in a small town of less than 20k people

Not weird at all. It’s much easier to run fiber in a small town than in a large city. Cities are denser and more crowded. It’s also more crowded underground. In a city you might have to close streets, you need to be more careful when digging because of all the other stuff underground.

All that makes it cheaper and easier to install fiber in small towns or smaller, less dense cities.

Look, I get you hate apple and desperately want to find fault with everything they do. I agree they are a bunch of greedy bastards that try to squeeze as much money out of their customers as they can, but this just isn’t one of the ways they do it. In fact it’s the exact opposite: it ensures old devices remain usable for longer.

The fuckers sold us devices that worked perfectly for years until they sent firmware updates to slow them down

This slow-down only triggers after the device already had a brown-out. That is: it has to at least crash once due to a worn out battery.

“The brakes on my car worked fine for years and now they suddenly don’t work anymore”. Batteries are a consumable. They wear out. Phones were crashing due to it. They pushed an update that ensured the devices remained usable instead of crashing under load.

Could they have communicated it better? Yes. Was it the right solution from a technical point of view? Also yes.

It doesn’t get progressively slower over time, it’s either in degraded mode or it isn’t.

If you want to use a car analogy, it’s comparable to limp mode. When your car detects an engine problem it goes into limp mode in which you don’t have full performance but you can at least get home. You’d rather have your car not do this and risk damaging the engine, or would you prefer it to simply stop working and leave you stranded?

Batteries wear out, it’s an unfortunate property of our current battery tech. You can either let your phone get unstable (risking data loss), have it refuse to work at all, or let its run in reduced performance mode so it at least stays usable. Those are your options. Pick one.