• 0 Posts
  • 10 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle
  • Eyron@lemmy.worldtoNews@lemmy.world*Permanently Deleted*
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    2 months ago

    You should probably read/know the actual law, rather than just getting it close. You’re probably referring to 18 USC 922 (d) (10), which includes any felony-- not just shooting. That’s one of 11 listed requirements in that section, which assumes that the first requirement (a) (1) is met: not an interstate nor foreign transaction. There’s a lot more to it than just “as long as you don’t have good evidence they’re going to go shoot someone”

    Even after the sale, ownership is still illegal under section (g)-- it just isn’t the seller’s fault anymore.

    This is basic information that should be known to any gun safety advocate. “Responsible” gun owners must know those laws, plus others backward and forward. One small slip-up is a felony, jail, and permanent loss of gun ownership/use. Are they really supposed to listen to those who can’t even talk about current law correctly?

    The law can be better, but you won’t do yourself any favors by misrepresenting it.




  • Do you use Android? AI was the last thing on their minds for AOSP until OpenAI got popular. They’ve been refining the UIs, improving security/permissions, catching up on features, bringing WearOS and Android TV up to par, and making a Google Assistant incompetent. Don’t take my word for it; you’ll rarely see any AI features before OpenAI’s popularity: v15, v14, v13, and v12. As an example of the benefits: Google and Samsung collaborating on WearOS allowed more custom apps and integrations for nearly all users. Still, there was a major drop in battery life and compatibility with non-Android devices compared to Tizen.

    There are plenty of other things to complain about with their Android development. Will they continue to change or kill things like they do all their other products? Did WearOS need to require Android OSes and exclude iOS? Do Advertising APIs belong in the base OS? Should vendors be allowed to lock down their devices as much as they do? Should so many features be limited to Pixel devices? Can we get Google Assistant to say “Sorry, something went wrong. When you’re ready: give it another try” less often instead of encouraging stupidity? (It’s probably not going to work if you try again).

    Google does a lot of wrong, even in Android. AI on Android isn’t one of them yet. Most other commercially developed operating systems are proprietary, rather than open to users and OEMs. The collaboration leaves much to be desired, but Android is unfortunately one of the best examples of large-scale development of more open and libre/free systems. A better solution than trying to break Android up, is taking/forking Android and making it better than Google seems capable of.


  • I’m still rocking a Galaxy Watch 4: one of the first Samsung watches with WearOS. It has a true always-on screen, and most should. The always-on was essential to me. I generally notice within 60 minutes if an update or some “feature” tries to turn it off. Unfortunately, that’s the only thing off about your comment.

    It’s a pretty rough experience. The battery is hit or miss. At good times, I could get 3 days. Keeping it locked, (like after charging) used to kill it within 60 minute (thankfully, fixed after a year). Bad updates can kill the battery life, even when new: from 3 days life to 10 hours, then to 3 days again. Now, after almost 3 years, it’s probably about 30 hours, rather than 3 days.

    In general, the battery life with always-on display should last more than 24 hours. That’d be pretty acceptable for a smartwatch, but is it a smartwatch?

    It can’t play music on its own without overheating. It can’t hold a phone call on its own without overheating. App support is limited, but the processor seems to struggle most of the time. Actually smart features seem rare, especially for something that needs consistent charging.

    Most would be better off with a Pebble or less “smart” watch: better water resistance, better battery, longer support, 90% of the usable features, and other features to help make up for any differences.


  • To me, your attempt at defending it or calling it a retcon is an awkward characterization. Even in your last reply: now you’re calling it an approximation. Dividing by 1024 is an approximation? Did computers have trouble dividing by 1000? Did it lead to a benefit of the 640KB/320KB memory split in the conventional memory model? Does it lead to a benefit today?

    Somehow, every other computer measurement avoids this binary prefix problem. Some, like you, seem to try to defend it as the more practical choice compared to the “standard” choice every other unit uses (e.g: 1.536 Mbps T1 or “54” Mbps 802.11g).

    The confusion this continues to cause does waste quite a bit of time and money today. Vendors continue to show both units on the same specs sheets (open up a page to buy a computer/server). News still reports differences as bloat. Customers still complain to customer support, which goes up to management, and down to project management and development. It’d be one thing if this didn’t waste time or cause confusion, but we’re still doing it today. It’s long past time to move on.

    The standard for “kilo” was 1000 centuries before computer science existed. Things that need binary units have an option to use, but its probably not needed: even in computer science. Trying to call kilo/kibi a retcon just seems to be trying to defend the use of the 1024 usage today: despite the fact that nearly nothing else (even in computers) uses the binary prefixes.


  • 209GB? That probably doesn’t include all of the RAM: like in the SSD, GPU, NIC, and similar. Ironically, I’d probably approximate it to 200GB if that was the standard, but it isn’t. It wouldn’t be that much of a downgrade to go to 200GB from 192GiB. Is 192 and 209 that different? It’s not much different from remembering the numbers for a 1.44MiB floppy, 1.5436Mbps T1 lines, or ~3.14159 pi approximation. Numbers generally end up getting weird: trying to keep it in binary prefixes doesn’t really change that.

    The definition of kilo being “1000” was standard before computer science existed. If they used it in a non-standard way: it may have been common or a decent approximation at the time, but not standard. Does that justify the situation today, where many vendors show both definitions on the same page, like buying a computer or a server? Does that justify the development time/confusion from people still not understanding the difference? Was it worth the PR reaction from Samsung, to: yet again, point out the difference?

    It’d be one thing if this confusion had stopped years ago, and everyone understood the difference today, but we’re not: and we’re probably not going to get there. We have binary prefixes, it’s long past time to use them when appropriate-- but even appropriate uses are far fewer than they appear: it’s not like you have a practical 640KiB/2GiB limit per program anymore. Even in the cases you do: is it worth confusing millions/billions on consumer spec sheets?


  • Eyron@lemmy.worldtoTechnology@lemmy.worldWhy a kilobyte is 1000 and not 1024 bytes
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    6
    ·
    edit-2
    11 months ago

    This is all explained in the post we’re commenting on. The standard “kilo” prefix, from the metric system, predates modern computing and even the definition of a byte: 1700s vs 1900s. It seems very odd to argue that the older definition is the one trying to retcon.

    The binary usage in software was/is common, but it’s definitely more recent, and causes a lot of confusion because it doesn’t match the older and bigger standard. Computers are very good at numbers, they never should have tried the hijack the existing prefix, especially when it was already defined by existing International standards. One might be able to argue that the US hadn’t really adopted the metric system at the point of development, but the usage of 1000 to define the kilo is clearly older than the usage of 1024 to define the kilobyte. The main new (last 100 years) thing here is 1024 bytes is a kibibyte.

    Kibi is the recon. Not kilo.