I have to disagree with all the negative criticism here. While the instructions may not have been entirely clear up front, actually playing the game just once clears everything up.
And I absolutely love color blending or sorting games, like Blendoku or I Love Hue, so I'll definitely keep playing this game, unlike Wordle or its other clones.
Thanks for creating Colorfle! Please don't change too much.
To me, it's not a problem that my code is used for commercial gain. I use the MIT licence (a permissive licence). The key thing for me is that it doesn't give companies a competitive advantage, rather it puts companies that don't use it at a competitive disadvantage. It's thanks to Open Source that I'm writing this on a system that uses 100% Open Source software (okay, maybe the BIOS isn't). A good thing about Open Source is that if a company uses it, they're more likely to report / fix bugs, which helps everyone.
> It's thanks to Open Source that I'm writing this on a system that uses 100% Open Source software
no, it's thanks to free software and the GPL. Thanks to open source you get Playstation and macOS which both use BSD to create the most proprietary system possible.
But how do you turn the lights off again? Timeout? Not detecting any motion? Also, do you have any pets?
As for dimming the lights, I'm sure it looks impressive and also dramatic. But I've been able to go to bed in time for more than 40 years just fine. Also, what if you do want to stay up later?
Which, I think, is the gist of the first comment: You can do all these things, but they don't improve the current status and thus mostly serve as recreational activity.
Turning off the lights is a big problem. You need to introduce presence detection, which is more than motion - people are very still when watching a movie or reading a book or working at their desk. That's when you have to introduce phone detection or heat detection or other sensors that need to be processed and integrated exploding the complexity.
The most common example I know of is that if in a garden grows an apple tree, where one branch reaches into the neighbor's garden, is the neighbor allowed to harvest the apples from that branch?
IANAL, but IIRC German law states that 1) the neighbor is allowed to harvest the apples and 2) the neighbor can demand from the tree owner to saw that branch off.
I don't know about the fruit specifically, but I believe that in most jurisdictions in the United States you can also demand that the neighbor remove the encroaching branch, or remove it yourself, if you so choose.
Usually it's better to just be friendly, though. When I used to home brew and grew hops along my back fence, my neighbor on the other side was also a home brewer. I told him he was welcome to any hops that were on his side of the fence. :-)
It probably helped that the fence was old and ugly, and being covered with hop vines make it look nice.
IIRC, in the US, tree law is a lot more complicated (which itself is fascinating).
For example, where I lived, it was my responsibility to trim my neighbors branches that were growing into and falling into my yard. Further, if I chose to cut said branches, I had to make sure it wouldn't harm or kill the tree.
As someone whose only experience with linux is servers and Raspberry Pi, can you tell me what's wrong with snaps? I've only used them on a self-hosted NextCloud and my experience with them has been decent, but I see a lot of dislike for them on HN.
There's pros and cons. It helps developers because they aren't restricted to the distro's shipped library versions, they can build against what they need. It also confines the app to a sandbox. The downsides are that the packages end up larger because they ship with all of the necessary bundled libraries (which can also increase memory usage of the application because it can't share the libraries loaded in RAM by the native operating system), and there's a lack of trust that the developer can keep up with bundled library security updates.
Also I think snap is an Ubuntu thing vs flatpak and appimage which are more distro agnostic. That's my issue with it/Ubuntu. They are doing good things, but at the same time I don't feel they are as "open" as other linux distros.
Also, snapd is installed by default on their servers and it's not as to remove as it should be.
This is one of the reason that I will always choose a different distro if I have the choice.
Does its sandbox work yet on distros that don't use apparmor? Last time I checked, snap apps were essentially unconfined on Fedora, and sandboxing is one of snap's most important selling points.
You have skipped quite a few downsides. Anyway, the biggest one is that what was previously an app is now a separate environment that is sometimes hard to control. If I wanted to run an app in a sandbox, I would have run it in a sandbox. People have run into all possible problems with snaps in the past, it has been discussed on HN ad naueseam [0] [1].
> Anyway, the biggest one is that what was previously an app is now a separate environment that is sometimes hard to control. If I wanted to run an app in a sandbox, I would have run it in a sandbox.
I see sandboxing as a major upside. Users expect sandboxing by default nowadays. Some game they downloaded shouldn't be able to intercept your online banking browser session. Yet, in the traditional Linux desktop model, they can.
Having app sandboxing by default is long overdue. Not having it makes the environment a second class citizen for user safety and security when compared to iOS and Android, for example.
> The downsides are that the packages end up larger because they ship with all of the necessary bundled libraries (which can also increase memory usage of the application because it can't share the libraries loaded in RAM by the native operating system), and there's a lack of trust that the developer can keep up with bundled library security updates.
This has basically been happening with browser debs anyway. Browser upstreams bundle their libraries, and distributions have increasingly been unable to unbundle them.
Background daemon that takes up CPU, proprietary store, slow startup, and automatic updates in the background. Flatpak is much better if you need some sort of sandboxing, or updates outside what your distro can provide.
Automatic updates are great, when I release security fixes like new Node.js version to Wekan https://wekan.github.io . It has worked well for me for many years.
Update install is very fast, with very small downtime, automatic database schema upgrades, etc.
Sandboxing is great, code can not write outside of app's own writeable directory.
Does Flatpak have any kind of automatic update ability?
Or is there any automatic update ability for some other package system on Linux/Windows/Mac ? Is Snap the only one?
Automatic updates are great until they kill your running app [1]. Flatpaks can be updated automatically through gnome-software or a cron job, but the user can decide whether to enable automatic updates. Snaps will forcibly update after 60 days even on metered connections.
Snaps are Ubuntu specific and the server side/repo is closed source.
Snaps pollute the df/mount points with per snap lines.
They rolled out in a LTS release with minimal testing. Caused quite a few problems like not being able to boot as multiple snaps drained /dev/random (instead of /dev/urandom) and waited on more entropy, which was god awful slow since the boot hadn't finished.
There was no automatic cleanup of older snaps.
Generally it just seemed like a silly proprietary setup that Canocial tried to claim had wide industry support, despite not having that support. I'm not against the ideas, but why not docker? Flatpak? AppImages?
I had some issues with one app not reading its config file, and wanted to strace it to see if it finds the config or not. Big surprise, cannot strace snap apps..
Unfortunately the container breaks certain extensions (e.g. keepassxc-browser). And that's ignoring the fact that, at least on my machine, the flatpak fonts look terrible for some reason and I often run into issues with the Gnome theme not being properly inherited.
Try flatseal and see if you can tweak the permissions.
Re: terrible look, I face the same thing with Telegram (the mouse reverts to whatever is the default in Qt and ignores the system settings). I haven't been able to fix that.
When installing distro, I usually remove some included packages and install newest Firefox, LibreOffice, Gimp, Inkscape etc from Flatpak, because Flatpak has newest versions. Many packages do not update .deb anymore, they have moved to Flatpak.
I uninstalled the snap, then did apt install firefox, worked fine. In principle I am all in favor of more sandboxing for my browser, but when I opened FF on the machine I'd upgraded to Impish, it didn't import anything, open tabs, bookmarks, nada. Not what I'd call friendly onboarding...
Possibly getting Firefox from Debian Sid (unstable). Will require some advanced apt configuration to make sure that nothing else accidentally comes from sid, and might break or require further apt configuration changes if it starts requiring library versions that aren't in Ubuntu.
I use Ubuntu and I sometimes install Debian Sid packages by downloading them in a browser and installing them with dpkg.
If you run stable, which is released as snapshots ala Ubuntu, the packages are ancient.
If you run testing, which is a rolling distro ala Arch, they're a lot newer and pretty solid, but security updates lag.
If you run unstable, which is also rolling, things can (rarely) break.
Additionally, Ubuntu has decided to incorporate non-free software and drivers right into the base product, which gives a better out-of-the-box experience. In Debian this is all opt-in and requires a bit more effort.
Now, I run Debian testing on my laptop, and I'm a huge fan of the distribution, not the least because Debian is the bedrock on which at least a half a dozen other distros are built. But I can acknowledge that their more conservative approach to packaging does have its downsides.
Exactly, Debian has you covered depending on your needs. I run Debian Stable on servers and Debian Sid on my desktop and laptop. Had 2 or 3 non-booting Sid systems over the course of 20 years, none or which weren't solved in 10 minutes after asking for help on IRC.
I doubt Ubuntu offers newer packages than my Debian Sid installation.
As for drivers and firmware etc as I've mentioned below I've installed a new state of the art desktop in recent weeks and everything simply worked. From the wifi to Bluetooth to the Nvidia gpu. I wouldn't call enabling the non-free repo "work" since it's just a question to answer during the installation...
> Exactly, Debian has you covered depending on your needs. I run Debian Stable on servers and Debian Sid on my desktop and laptop. Had 2 or 3 non-booting Sid systems over the course of 20 years, none or which weren't solved in 10 minutes after asking for help on IRC.
Oh sure, has Debian testing or unstable resulted in a non-booting system for me in the 15-20 years I've been using it? No. But that's an incredibly low bar to set. Issues absolutely pop up that, while not that catastrophic, remain problematic.
Just recently (like, in the past 2-3 weeks) the move from pipewire 0.3.36 to 0.3.37/38 broke bluetooth audio for me, which is a dealbreaker as I use a headset every single day for work. No idea why, but I had to go pull the previous package versions from /var/cache/apt/archives (thank goodness I didn't run a purge!), manually install them with dpkg, then pin them in my apt policy until the issue is fixed.
Similarly, the wifi drivers that ship with the kernel have periodically broken and worked again across major kernel versions.
These sorts of intermittent surprise issues are far less likely to happen with a snapshot distro due to the stability of the package set and the additional testing those snapshots undergo before being released.
The problem is the Debian snapshot distro is stable which, again, has an ancient package set.
Ubuntu strikes an interesting middle ground, giving you up-to-date packages that are vetted and then the whole distro is snapshotted which minimizes the potential for surprise breakage.
Now, again, I use Debian testing. I'm fine dealing with the intermittent issues that pop up. I know the system well enough to diagnose issues, manually downgrade packages if needed, pull things from sid if I have to, or even build packages by hand when absolutely necessary.
It works out of the box for most hardware, install proprietary things easily, including drivers and codecs, and have more up to date softwares. It also have lots of usability tweaks.
You can, have all that with debian, but then you have to do the work.
I don't want to do the work if canonical can do it for me.
I installed debian just a few weeks ago on my brand new desktop. AMD Ryzen 5800x, MSI B550 motherboard, MSI Nvidia RTX 3060 Ti. Everything worked, out of the box, without adding anything magical. Including Ethernet, wifi, Bluetooth and hardware accelerated graphics. Have been buying Nvidia gpu's since forever and their (proprietary) drivers have never let me down.
So I'm not sure what you're talking about. Also, more up to date software, I'm quite certain my Debian Sid has more recent versions of everything compared to what Ubuntu has.
Yeah, I've met those kind of comments for 15 years.
There is always somebody to say that in those kind of threads. Same as Vi is easy, try Manjaro, Nix, this latest implementation of LISP, that NoSQL db, this DSL, etc.
I used to give them the benefit of the doubt, spend some time testing the alternative the person talked about, came out disappointed, and wasted time.
Now I just trust numbers. When 100 people like you will tell me the same for 3 years, I will try.
In their mind it makes sense: firefox is a user facing app that is frequently updated and requires a lot of dependencies. Perfect candidate for a snap.
But yeah, up to now, snaps really sucked, and flatpak is winning.
While that is true, there are also people who don't drink and drive, don't text while driving, don't drive while overly fatigued, etc. So it's reasonable for those people to not want to use a system that's only as good as an "average" driver.
> So it's reasonable for those people to not want to use a system that's only as good as an "average" driver.
But... no one is forcing anyone to use this system. They elect to. Thus this is the wrong question, but rather if drivers should be given the option to use the system.
If anything it might be reasonable to infer that poor drivers are more likely to use this system, so the standard could plausibly be below that of an average driver while still improving overall safety.
I hate to put it this way, but I think it'll be easier to get people to use autopilot (that performs better than your average driver) than it will be to get people to get gud at driving.
You're an attentive driver right? You've probably noticed people lane changing without looking, causing or almost causing collisions. Or jockeying for position fruitlessly. Or being drunk or getting sleepy. Or getting aggro. Back when I was driving a lot I would have been grateful for anything that meant I wouldn't have to drive around people like that.
I dunno where I'm going with this exactly, I suppose we've had similar experiences and it makes me a little surprised that you'd be against automated systems bringing the skill floor up.
And I absolutely love color blending or sorting games, like Blendoku or I Love Hue, so I'll definitely keep playing this game, unlike Wordle or its other clones.
Thanks for creating Colorfle! Please don't change too much.