I mean, you could do that, it's sort-of a lie though, maybe something better would be using the date of the most recent commit, which would be both more accurate, as far as authorship goes, and actually deterministic..
Pipe something like this into your build system:
date --date "$(git log HEAD --author-date-order --pretty=format:"%ad" --date=iso | head -n1)" +"%Y"
I'm sorry, I didn't understand, are you claiming that gamers (perhaps one of the most notoriously toxic communities) are not hostile towards game developers?
Ahhh context was missing. I meant in actual game development discords for game developers, not games that have discords from the developers.
My anecdotal data is based on observations from my partner who has boughten several asset packs from itch.io, got on the discord for support, and the artists/game devs have been extremely unwelcoming to the point of just banning users for simple game dev questions and/or mentions of AI.
Of course, gamers (competitive) are generally a toxic bunch.
> extremely unwelcoming to the point of just banning users for simple game dev questions and/or mentions of AI.
This is understandable when you realize that artist are being accused of using AI for every single imperfection in art now. You messed up on perspective? You must be using AI. Anatomy is slightly off? You must be using AI. At a certain point they just get tired of the accusations and choose to ban people.
I can believe that scenario, but I believe in the cases I've seen regarding game dev, It's more pearl clutching from the artists (rightly so) rather than accusations from the asset users.
> worshipping at the thrown of backwards compatibility is one reason that Windows is the shit show it is
You say Windows is a shit show, but as someone who has developed a lot on both Windows and Linux, Linux is just as much a shit show just in different ways.
And it's really nice being able to trust that binaries I built a decade ago just run on Windows.
I have a legally-purchased copy of Return to Castle Wolfenstein here, both the Windows version and the official Linux port.
One of them works on modern Linux (with the help of Wine), one of them doesn't.
I wrote some specialist software for Linux round about 2005 to cover a then-business need, and ported it to Windows (using libgtk's Windows port distributed with GIMP at the time.) The windows port still works. Attemping to build the Linux version now would be a huge ordeal.
What older architecture? Windows has been on x86 for decades. You should be able to run any 32-bit application built 20+ years ago on modern Windows, assuming the application didn't rely on undocumented/internal Windows APIs.
It has no driver standard on purpose with the intention of getting drivers into the mainline kernel tree.
If drivers are "standard" then low quality drivers full of bugs and security vulnerabilities proliferate and only the OEM can fix them because they're closed source, but they don't care to as long as the driver meets a minimum threshold of not losing them too many sales, and they don't care about legacy hardware at all or by then have ceased to exist, even if people are still using the hardware.
If there is no driver standard then maintaining a driver outside the kernel tree is a pain and more companies get their drivers into the kernel tree so the kernel maintainers will deal with updating them when the driver interface changes, which in turn provides other people with access to fix their heinous bugs.
The drivers for most PC hardware are in the kernel tree. That part is working pretty well.
It's clear that something more aggressive needs to be done on the mobile side to get the drivers into the kernel tree because the vendors there are more intransigent. Possibly something like right to repair laws that e.g. require ten years of support and funds in escrow to provide it upon bankruptcy for any device whose supporting software doesn't have published source code, providing a stronger incentive to publish the code to avoid the first party support requirement. Or greater antitrust enforcement against e.g. Qualcomm, since they're a primary offender and lack of competition is a major impediment to making it happen. If Google wanted to stop being evil for a minute they could also exert some pressure on the OEMs.
The real problem is that the kernel can't easily be relicensed to directly require it, so we're stuck with indirect methods, but that's hardly any reason to give up.
I don't think I'd put the difference between the pc and server markets vs mobile down to vendor "intransigence". Rather, I would say it's a result of the market incentives. For PCs and especially for servers, customers insist that they can install an already released OS and it Just Works. This means that vendors are strongly incentivised to create and follow standards, not to do odd things, and to upstream early. On the other hand in mobile and embedded there is basically no customer demand to be able to run preexisting distro releases, and so vendors feel very little pressure to put in the extra work to get support upstream or to avoid deviating from common practice. On the contrary they may see their custom deviations as important parts of what makes their product better or more feature rich than the competition.
Right to repair laws as you suggest might do something to shift the incentives of vendors in these markets; I don't think they're ever going to "see the light" and suddenly decide they've been doing it wrong all these years (because measured in commercial consequences, they haven't)...
> On the other hand in mobile and embedded there is basically no customer demand to be able to run preexisting distro releases
This is not a difference in customer demand. The customers are by and large the exact same people and the inability to do this has been a major longstanding complaint of phone customers, both from the nerds who want a real third party OS and the ordinary users who are frustrated that the OS on the phone they only bought two years ago is already out of support and the device can't have any currently supported OS from any source installed on it even though there is no good reason it couldn't at least run the current version of vanilla Android.
The difference is a difference in competition. There are a thousand PC OEMs and you can start one in your garage by assembling PCs from parts. The parts are made by a variety of companies (Asus, Gigabyte, ASRock, MSI, SuperMicro, etc.) If PC OEMs started locking the OS to the device so you had to buy a new PC every three years, they would lose customers to ones that don't, because customers would actually have a choice. Even Apple doesn't prevent Asahi Linux from running on Apple Silicon Macs.
The phone market is much more consolidated. Suppose you want a normal ~$300 phone with similar specs to other Android phones at a similar price point, but with an unlocked boot loader and in-tree kernel drivers. It doesn't exist. Customers can't express a preference for it because it isn't available, and the market is sufficiently consolidated that the incumbents benefit more from lock-in and planned obsolescence than they would from gaining market share by providing customers with what they want. Because the companies who do that first would be the small ones or startups who use it to gain market share, but the barriers to entry are kept high through vertical integration because of the lack of antitrust enforcement.
> On the contrary they may see their custom deviations as important parts of what makes their product better or more feature rich than the competition.
This is, to begin with, questionable. Phone customers are not buying phones over "custom deviations". They care about cameras and storage and battery life and price. Nobody wants custom buggy bloatware from the hardware company.
But regardless of that, it's orthogonal to the issue. There is nothing about Vendor Cloud AI Thing which is incompatible with having the drivers in the kernel tree.
> I don't think they're ever going to "see the light" and suddenly decide they've been doing it wrong all these years
Do some trust busting and see what having actual competition does to their behavior.
It's absolutely on purpose. But the tradeoff is Linux has become a really great server OS (because the kernel team can quickly refactor flawed code), but a poor desktop OS (because drivers are harder to ship than on Windows). This tradeoff isn't really well-known or debated in the Linux community, it just kind of exists.
I sort-of feel like maybe Pebble isn't for you, it had always been the smartwatch in a world of fitness trackers.
I'm almost the opposite for your, Notifications, then watch functionality, and card payments are primary for me. For me, fitness, and health tracking are barely secondary.
Which, IMO, is what I've always loved about Pebble, it was a smartwatch first.
Yeah, if you're development process requires LTO you may be holding it wrong....
Specifically, if LTO is so important that you need to be using it during development, you likely have a very exceptional case, or you have some big architectural issues that are causing much larger performance regressions then they should be.
Being able to choose a middle ground between development/debug builds and production builds is becoming increasingly important. This is especially true when developing in the browser, when often something appears to be slow in development mode but is fine in production mode.
WebAssembly and lightweight MicroVMs are enabling FaaS with real time code generation but the build toolchain makes it less appealing, when you don't want it to take half a minute to build or to be slow.
> Yeah, if you're development process requires LTO you may be holding it wrong....
I spent a few months doing performance optimisation work. We wanted to see how much performance we could wring out of an algorithm & associated data structures. Each day I’d try and brainstorm new optimisations, implement them, and then A/B test the change to see how it actually affected performance. To get reliable tests, all benchmarks were run in release mode (with all optimisations - including LTO - turned on).
I see a lot of love for the Bic Cristal, Personally, I love the Muji Gel Ink 0.38, I'm an infrequent writer, so take it with a huge grain of salt, but I find it a really pleasant pen, and cheap enough that I can have them wherever I need them.
Honestly, not great, but that's the world we live in.
reply