• 0 Posts
  • 32 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

  • It’s likely CentOS 7.9, which was released in Nov. 2020 and shipped with kernel version 3.10.0-1160. It’s not completely ridiculous for a one year old POS systems to have a four year old OS. Design for those systems probably started a few years ago, when CentOS 7.9 was relatively recent. For an embedded system the bias would have been toward an established and mature OS, and CentOS 8.x was likely considered “too new” at the time they were speccing these systems. Remotely upgrading between major releases would not be advisable in an embedded system. The RHEL/CentOS in-place upgrade story is… not great. There was zero support for in-place upgrade until RHEL/CentOS 7, and it’s still considered “at your own risk” (source).


  • CountVon@sh.itjust.workstoProgrammer Humor@lemmy.mlPunch cards ftw
    link
    fedilink
    English
    arrow-up
    50
    ·
    edit-2
    5 months ago

    One of my grandfathers worked for a telephone company before he passed. That man was an absolute pack rat, he wouldn’t throw anything away. So naturally he had boxes and boxes of punch cards in this basement. I guess they were being thrown out when his employer upgraded to machines that didn’t need punch cards, so he snagged those to use as note paper. I will say, they were great for taking notes. Nice sturdy card stock, and the perfect dimensions for making a shopping list or the like.



  • I’m sure there would be a way to do this with Debian, but I have to confess I don’t know it. I have successfully done this in the past with Clover Bootloader. You have to enable an NVMe driver, but once that’s done you should see an option to boot from your NVMe device. After you’ve booted from it once, Clover should remember and boot from that device automatically going forward. I used this method for years in a home theatre PC with an old motherboard and an NVMe drive on a PCIe adapter.


  • People here seem partial to Jellyfin

    I recently switched to Jellyfin and I’ve been pretty impressed with it. Previously I was using some DLNA server software (not Plex) with my TV’s built-in DLNA client. That worked well for several years but I started having problems with new media items not appearing on the TV, so I decided to try some alternatives. Jellyfin was the first one I tried, and it’s working so well that I haven’t felt compelled to search any further.

    the internet seems to feel it doesn’t work smoothly with xbox (buggy app/integration).

    Why not try it and see how it works for you? Jellyfin is free and open source, so all it would cost you is a little time.

    I have a TCL tv with (with google smart TV software)

    Can you install apps from Google Play on this TV? If so, there’s a Jellyfin app for Google TVs. I can’t say how well the Google TV Jellyfin app works as I have an LG TV myself, so currently I’m using the Jellyfin LG TV app.

    If you can’t install apps on that TV, does it have a DLNA client built in? Many TVs do, and that’s how I streamed media to my TV for years. On my LG TV the DLNA server shows up as another source when I press the button to bring up the list of inputs. The custom app is definitely a lot more feature-rich, but a DLNA client can be quite functional and Jellyfin can be configured to work as a DLNA server.




  • Atlassian doesn’t even have consistency within single products! I’m using Jira Cloud at work, and while most fields support markdown (e.g. three backticks to start a code block) there are a few that only support Jira’s own notation (e.g. {code} to start a code block). It’s always infuriating when I type some markdown in one of the fields that doesn’t support it for some inexplicable reason.


  • The technical issues could probably be tackled, but realistically I doubt we’ll ever return to the screener copy glory days. By now everyone who receives a screener copy knows about the watermarking software, and release teams would have a hell of a time convincing them that the watermark can 100% for sure be removed. The person in possession of the screener copy has every incentive not to share it, since the costs of getting caught are so high (fired and/or sued and/or blacklisted in the industry).

    I don’t have any source for this, but screener copy leaks were so prevalent at one point that I have to imagine that money was changing hands. Release teams behind paid sites were probably bribing recipients of screener copies so their site could have the pirate copy first, and later it would spread to free sites. Given the number of people that receive screener copies, studios realistically had no way to figure out who was leaking them so it was essentially free money for the leaker. The price paid to the leaker was probably not all that high since the risks were so low.

    As soon as the watermarks were in, the risks for the leaker went up dramatically and so would their price. Watermarking was actually a very clever solution to the problem. Rather than adding DRM, which would bog down their workflows and piss off their customers, studios added watermarks that made it uneconomical for the leaks to continue.


  • That sounds like a workprint. The linked wiki page has notable examples of workprints that made their way onto Internet, sometimes before the movie was even in theaters. I don’t think this is typically a sought-after version for pirate groups, their existence is likely more of a convenience situation. Someone got their hands on the workprint, uploaded it online, and it spread from there.

    The holy grail for pirate groups used to be screener copies, finished versions of films that are sent to reviewers, promoters, etc. before release. I remember a (relatively brief) time when finished copies of movies were routinely popping up online even before they were in theaters. Such leaks have largely been stopped by difficult-to-remove watermarking of screener copies and workprints. Every such copy that goes to an editor, VFX house or film reviewer gets its own unique watermark trace embedded in the copy. If the studio finds that your copy was leaked online they can fire / sue / blacklist you. It’s massively curtailed such leaks.


  • Oracle is shit because they use Red Hat works, providing contract on top of it… and only add UEK as … “better option” …

    That’s something they were allowed to do. It’s something everyone was allowed to do. FOSS means free and open source for everyone, even people and organizations you don’t like. Otherwise it’s not really free (as in freedom), now is it?

    Also, the “contract on top of it” is this license, which is a pretty short read. In my view it’s a very inoffensive license compared to Red Hat’s coercive license.

    Also also, they’re forking Oracle Linux from RHEL as of 9.3, so they’re won’t be “taking” from Red Hat in future anyhow.

    They (oracle) do contribute some on mainline kernel, but by making RHEL copy paste and only add UEK and their product… ugh… I don’t know.

    It drives me nuts when I see people imply that Oracle was somehow “stealing” from Red Hat by creating a downstream distro. It’s not theft when the thing being taken was free and open source! So Oracle copy-pasted RHEL, made some changes and redistributed it. So what? That’s something everyone was allowed to do, as long as they didn’t violate the open source license while doing it. Oracle isn’t violating the open source licenses, the sources are freely available, so why should I fault them for doing what they did?

    I think you’re also overlooking how much Oracle Linux actually benefited Red Hat themselves. By making Oracle Linux a downstream distro and testing all the Oracle software on it, I’d argue that Oracle actually made RHEL more valuable by increasing the number of enterprise workloads RHEL could support. Yes, a customer could theoretically get support from Oracle instead of Red Hat, but hardly anyone actually did that. I see real-world Oracle Database installs every day and the majority of them are on Red Hat Enterprise Linux proper. Very few are on a downstream. Every one of those RHEL installs is a paying Red Hat customer.

    Oracle didn’t do all that out of the goodness of their hearts of course, they did it because their customers wanted to standardize on one OS and Oracle wanted to sell them database (and other) software. They did it for profit, but there’s nothing inherently wrong with that. Both Oracle and Red Hat profited from that arrangement. Every enterprise Linux user indirectly benefited from the arrangement too, because it meant there was a less fragmented OS ecosystem to build on! But now Red Hat wants to alter the deal, Vader-style, Oracle is forking Oracle Linux, and you know who loses the most in all of this? All of those users who previously enjoyed the benefit of a less fragmented enterprise OS landscape, myself among them. As far I’m concerned, the blame for that lies squarely at Red Hat’s feet.



  • I was actually kind of hoping for the second option, if only so that it would be Oracle footing the legal bill to establish a precedent. That Oracle didn’t choose this option may indicate that Red Hat’s coercive license wrapper (“if you exercise your open source rights to redistribute, we’ll close your account”) is actually an effective and legal end-run around open source licenses. I don’t want that to be the case.


  • From a practical standpoint, we believe Oracle Linux will remain as compatible as it has always been through release 9.2, but after that, there may be a greater chance for a compatibility issue to arise. If an incompatibility does affect a customer or ISV, Oracle will work to remediate the problem.

    This is the part of the post I find most interesting. Looks like Oracle won’t be engaging in whatever workarounds Rocky Linux and AlmaLinux are using to continue operating as downstream distros of RHEL. Instead, if I’m reading this correctly it means Oracle Linux will essentially be forking from RHEL past 9.2. There were essentially three options before Oracle when Red Hat made their license change:

    • Pay Red Hat for RHEL licenses. Lol as if, Larry Ellison didn’t become a billionaire by spending money he didn’t need to.
    • Use whatever workarounds to remain a downstream distro and pay Red Hat nothing, while using their army of lawyers to fend off any ensuing lawsuits from Red Hat / IBM. It’s not like they couldn’t afford to fight the case after all.
    • Fork from Red Hat.

    That they’ve chosen the third options is kind of fascinating to me, and to understand why you’d probably need to understand how enterprise database support works. The Oracle databases I see day to day are massive, and they drive practically all of a company’s core operations. Unanticipated downtime is fucking expensive, so these companies are willing to pay a lot for top-tier support (not like I think Oracle Support is actually good, mind you, but that’s a whole other topic). The DBAs running these databases don’t want to deal with any headaches whatsoever, so they’re only going to install Oracle on approved operating systems. They can’t afford to have Oracle say “nope, sorry, unsupported platform” during an outage.

    For a couple decades now, the supported Linux platforms for Oracle Database have been RHEL, SLES and Oracle Linux. Obviously Oracle Linux will remain on that list, and I doubt SLES is going anywhere either (it tends to be popular in Europe), but does RHEL drop off the list in future? Does Oracle think they can actually convert RHEL installs to Oracle Linux installs at customer sites? Or does RHEL stay on the list but become the red-headed step-child? Either way, this feels like an attempt by Oracle to erode the value of Red Hat’s platform. It’ll be interesting to see how it plays out.


  • If anything, I’d like to see them put their money where their mouth is and hire Linux devs to continue Oracle Linux in an open manner.

    Oracle Linux is already open: https://yum.oracle.com/. ISOs and full sources are freely downloadable, you don’t even need to create an account, and the Oracle Linux license explicitly states that you retain all your open source rights to any open source software distributed as part of Oracle Linux. I suppose it would be possible for Oracle to change their license to make it more akin to Red Hat’s and thus make Oracle Linux less free, but there’s been no sign of Oracle looking to do that.

    Oracle also definitely has lots of Linux devs. They even throw some shade at IBM in the post:

    By the way, if you are a Linux developer who disagrees with IBM’s actions and you believe in Linux freedom the way we do, we are hiring.

    They need those Linux devs because all of Oracle Cloud and Oracle Exadata are built on Oracle Linux, and Oracle tests their main cash cow Oracle Database exclusively on Oracle Linux. I think that last point is actually the reason that Oracle Linux even exists. I don’t think Oracle cares too much about owning the OS layer, they want to be able to support their Database product on an OS that the majority of their customers are using without having to pay a tax to the OS vendor.

    I also work on a product that has to interoperate with RHEL, and I also want my company to be able to test our product without having to pay a tax to Red Hat. I’m quite happy to see this blog post from Oracle because it shows that our aims are aligned and it means we’ve got an 800 lb. gorilla on our side of the line. Entirely possible Oracle could turn around and do the same things, but I’ve got no compunctions about cheering them on while our aims coincide.



  • Anyone who uses Oracle Cloud is either directly or indirectly using Oracle Linux. Oracle Cloud is ~2% of the cloud market, so it’s small compared to the big three (AWS ~32%, Azure ~23%, GCP ~10% according to this report) but 2% of a very big market (~$237 billion total estimated for 2023) is still a significant user base.

    From my own work, most of the Oracle Cloud adoption I see appears to be driven by favourable prices for Exadata Cloud as compared to purchasing on-prem Exadata hardware. Oracle Linux is also baked into Exadata “Cloud-at-Customer”, which has essentially the same cloud control plane but the hardware and all data lives on-prem at the customer’s site. That seems fairly popular with customers who want Exadata performance but can’t allow their data to leave their premises for security reasons.


  • I hate that companies can rug pull things their customers have enjoyed, and come to rely on for such a long time.

    Yeah, that’s probably part of why I feel so strongly about this. I relied on CentOS in my dev/test pipeline for years, so I’m effectively one of the individuals that was rug-pulled. Will Red Hat now try to squeeze us for license revenue again, at a time when sales are tight and cost controls are even tighter? Will I need to rework my dev/test pipeline to use AlmaLinux or RockyLinux, and maybe rework it again if Red Hat’s restrictions end up making those not a 1-for-1 replacement for RHEL testing? The uncertainty is unwelcome.

    But if they had restricted it in the first place and no one ever built things on top of it in the first place - I am not 100% convinced that is as morally wrong.

    Possibly not, though I have to wonder whether Red Hat would still enjoy their current market position if they hadn’t been allowing this to begin with. That others could easily build on top of what they built is part of what made RHEL probably the dominate enterprise Linux distro on the market today. It’s the one I see installed most often at customer sites at any rate.

    I’m not sure this maps 1-to-1, but it feels like Red Hat might end up enshittifying their own OS in an effort to extract more revenue from it. Doing so could easily backfire on them. Any restrictions they add to generate more revenue also add friction for third-party developers looking to interoperate with the OS. Some of them may choose to stop directly supporting RHEL as a result. Too much of a pain, let some RHEL customer take care of that. But most Red Hat customers are paying for RHEL because they don’t want to do those sorts of things. They want to install the OS, install the software they need, and get on with whatever their core business happens to be. Over time, this could corrode the value of RHEL itself.


  • I use much of the servarr set for core functionality. Radarr for movies, Sonarr for TV show, Bazarr for subtitles, Prowlarr for indexing. Those are the management tools for the media. If I want to delete something off the HTPC, I delete it from Radarr/Sonarr and let them handle cleanup of the library.

    Qbittorrent does the downloading, and the free version of Serviio handles DLNA streaming to display devices. All I want is software that streams to display devices while handling transcoding if needed, and Serviio does that. I’ve tried Plex and Jellyfin in the past, but I felt like they both attempted to do more than I needed while actually accomplishing less than I wanted. It’s been a while since I tried either of those though, so things might be different now.

    All of this is running in an old HTPC case containing the parts from the prior incarnation of my gaming PC, plus half a dozen 4TB hard drives. It’s wildly over-specced for what I ask it to do, which has given me plenty of headroom to play around with self-hosting stuff like ViewTube and SearXNG.