Everything starts as a stock phx.new app which use sqlite by default. Nothing is specific to fly. You should be able to copy the git clone url, paste, cd && mix deps.get && mix phx.server locally and the app will just work.
Personally I found System 7.6/Mac OS 8’s Platinum to be a step up in usability compared to System 7 and before. The light mid-gray it used in most of its UI was pleasant and easier on the eyes than the stark white that made up the majority of the original Mac UI, but it was still plenty legible.
The System 7.0 UI appearance - before Platinum - was a mess. It was little more than a partially colorized version of the monochrome System 6 user interface; in fact, it mostly fell back to the System 6 appearance on machines with monochrome displays, like the (brand-new in 1991!) PowerBook series.
In a certain sense, Platinum was an attempt to reinterpret what Mac OS could have looked like if it had always been designed for a color display. It didn't just add color, like System 7.0 had; it added depth and texture to the interface which wasn't practical to display before. It also added a ton of new controls to the toolkit which previously didn't have standardized implementations or appearances. (For instance, System 7.0 didn't have a standard progress bar control - every application which used one had to provide their own implementation.)
There were plenty of Kaleidoscope schemes and Appearance Manager themes for those with Macs who liked Aqua but either couldn’t or didn’t want to upgrade to OS X yet. There were some interesting “remixes” of Aqua too, including one that gave it BeOS-like tab titlebars!
There was even one Aqua scheme that through some feat of wizardry managed to give menus soft, 32-bit transparency drop shadows just like OS X had. I have no idea how that worked, classic Mac OS itself was only capable of 1-bit transparency as far as I'm aware.
The classic Mac OS (Toolbox) menu routine took over exclusive use of the machine when it was tracking the mouse in the menu - all multitasking stopped running.
So an extension could draw whatever fancy effect it wanted when the menu was down without worrying about a background application drawing over it (drawing over the transparency) as long you made sure to restore what was beneath when the menu was let go.
There were extensions that got around this, though. iTunes for the classic Mac OS (and I'm pretty sure SoundJam before it) could continue to play music with a menu open, for example.
Yeah you could do things like set timer interrupts, and starting in somewhere like MacOS 8.6 there was an actual multitasking (and multi-CPU) nanokernel running beneath everything that allowed you to schedule tasks in a more modern way.
But those tended to have some pretty gnarly limitations (like I think in interrupts you can't allocate memory) so AFAIK they were only used for stuff like real-time audio, I dunno if anyone ever used those to do screen drawing, so in practice I can't think of anything that would interfere with menu drawing.
No, Quickdraw in 7.5 and higher (maybe before) supported 8 bit alpha channels. Classic MacOS didn't have a compositor, so redrawing windows was constant and expensive and I guess this was why they didn't do soft drop shadows.
I think it could also be worthwhile to figure out ways to:
- Avoid requiring the user to figure out how to get into BIOS/EFI and change boot order. Windows has APIs for manipulating EFI things, may be worth looking into that.
- Replace GRUB with something more modern like rEFInd or Clover with a nice looking theme.
For the latter point, while GRUB is technically functional, it looks scary and arcane to new users and has little resiliency to things like Windows updates mucking with boot entries. It makes for a bad first impression (“why is my computer showing hacker screens suddenly”) and when it breaks your average user doesn’t have a prayer of fixing it. Something that looks more modern and self-heals would be a big improvement.
> - Replace GRUB with something more modern like rEFInd or Clover with a nice looking theme.
Replace Grub with nothing. If you're not doing bootable snapshots like openSUSE, then there is virtually no benefit in a "boot loader". The linux kernel + cmdline (+other stuff like ucode or secure boot signing stuff) can easily be packed into a single bootable .efi file.
That efi file will then get an entry in your uefi boot device list just like windows already has/had. This way is better anyway, since windows will overwrite your uefi boot order with every significant update, meaning users will already need to know how to boot other os's.
How do you anticipate users choosing Windows or Linux at boot time without a bootloader?
If the idea is they go cold turkey full Linux, good luck with that.
if the idea is they use their UEFI firmware boot menu, you're forgetting how unintuitive that is for most users with most uefi interfaces (spam hotkey at boot, wait for slow loading uefi, navigate to subscreen with boot order, find right menu item, either reorder and save or press F-key combo to "boot once now")
I've not had a MB where you had to spam any key. Just hold it on boot and wait until you see the menu. Select the one you want to boot now with either mouse or keyboard. This doesn't usually change the default boot order.
If you managed to install linux then this really shouldn't be a thing to get hung up on.
If you don't understand why GRUB's (or refind or systemd-boot) boot menu is preferable to your UEFI interface, then I'm glad your solution works for you.
Wouldn’t things like iCloud Private Relay and other VPN-ish things throw a wrench into IP-geo-based tracking? Seems like it’d make the targeting so broad as to be useless.
As an aside, we just spent a couple of weeks camping in our RV with a cellular router connected to a VPN at home. Now that we're back home, Google maps (on a non-GPS equipped device) and Roku still think we're at the campground several states away. I guess my GPS equipped tablet reported the new location of our home IP address. On past experience, it takes about a week to reset.
I don't know a lot about iCloud in particular, but in general there are not enough active VPN users to make a noticeable difference in tracking. By its nature ad tracking does not have to be super accurate in the aggregate to beat a wild guess.
Conveniently for them, iCloud private relay only really impacts browser usage, third party apps are only impacted when using unencrypted connections, which is unlikely.
I think it’s pretty common for people to be able to perceive PWM flicker in their peripheral vision that they can’t when looking directly at the source. I encounter this fairly regularly myself.
Nah, LED lighting generally uses at least 200 Hz at a minimum. Some up to kHz. You can't perceive that. Older stuff or cheap quality might be using un-rectified AC/DC which you can see. Like cheap Xmas lights.
I very easily can. I had to get rid of an otherwise good monitor a few years ago before I knew it used PWM to control the backlight (and before I even knew PWM was used at all for this functionality — I only had experience with CCFL backlight before that).
It was really annoying to look at, like looking directly at cheap fluorescent lighting. Miraculously, setting brightness to 100% fixed the issue.
By googling around, I found that it used PWM with a modulation frequency of 240 Hz, with a duty cycle of 100% at full brightness, which explained everything.
I can also easily perceive flickering of one of my flashlights, the only one that uses PWM at a frequency of a few hundred hertz. Other flashlights either run at multiple KHz, or don't use PWM at all, and either one is much easier on the eyes.
Some of us really do perceive this stuff, which can be hard to believe for some reason.
Like back when CRTs were mainstream you'd have those computer labs with monitors set to 60-85Hz and most people wouldn't notice, but some would. I definitely did, I couldn't stand looking at a CRT set to less than 100 Hz for more than an hour.
Absolutely, I also had massive issues with them, ending with red eyes and headaches within an hour of use. Getting my first LED monitor (with a CCFL backlight) was out of this world.
In gaming situations what they perceive may not be the actual "flicker" of frames but the input->to->display latency, which is a very different thing to notice.
Hue bulbs have pretty bad CRI actually. They only claim >80, which almost any LED bulb is capable of these days. A good LED bulb (include those made by Philips these days) have a CRI >95.
Depends on the bulb. For those of us with "fast" eyes, some LED bulbs that are just fine for others are a subtly flickering infuriation generator.
You may not believe that people that can see 120->240Hz flicker exist, but we do. In this era of frequently-cheap-ass LED lighting, it's a goddamn curse.
> ...between cheap LEDs and expensive ones (hue)...
If so, they're referring to the Hue brand of bulbs, rather than the color property. More evidence for the fact that they're talking about flicker is that they quoted this to indicate that they were replying to it:
> > Nah, LED lighting generally uses at least 200 Hz at a minimum. Some up to kHz. You can't perceive that.
I had to shop around a LOT before I could find LED headlight bulbs with just a fan and a bare-ass resistor for current control so I wouldn't see that forsaken flicker.
It's really bad for me as I work in an LED and LASER facility. I handle ALL the PWM stuff while everyone else handles the simple led/resistor/connector board assemblies. EVERYTHING FLICKERS.
My thanks to you for shopping around for non-shit headlights. For a long, long while it seems like every third car had strobing headlights. (Now, the primary problem is INTENSELY bright and poorly-aimed headlights. I'm not sure which is worse, to be honest... but both SHOULD be super illegal.)
> EVERYTHING FLICKERS.
I absolutely could not handle that. My sincerest condolences.
> Nah, LED lighting generally uses at least 200 Hz at a minimum.
Eh, they use what they can get away with. Nobody is out there policing flicker rates. Especially when you add a dimmer into the mix, there's a lot of room between good and bad, and when you're at the hardware store buying bulbs, there's not much to indicate which bulbs are terrible.
Lots of people don't seem to notice, so the terrible ones don't get returned often enough to get unstocked, and anyway, when you come back for more in 6 months, everything is different even if it has the same sku.
Actually, Energy Star and California's Title 24 have flicker standards. They may not go as far as some people like, but you can look for these certifications to know that a bulb at least meets a certain minimum standard.
The range of HomeKit-enabled doorbells and cameras is disappointing to begin with and even worse when removing options that require a proprietary adapter box and/or subscription. The best option at the moment seems to be a Ubiquiti setup that integrates into HomeKit by way of Homebridge or other similar solutions rather than anything that supports HomeKit specifically.
Any sort of automation in Home app besides 2-3 line demo is quickly turning into nightmare, you are locked in bunch of annoying limitations and devices are always costing more than open source alternative.
It’s the smart home ecosystem that the FOSS world has kind of coalesced around, though (see HomeBridge, HomeAssistant, etc). The others are all much more centered around someone else’s servers and subscriptions and offer little to no possibility of running things locally.
Yes I run Home Assistant too. Also got quite a bit of devices on Aqara's platform, and a device each on Ewelink, Tuya, Meross which all technically are a platforms. There's probably another 5 devices with their own apps. Tasmota + Home Assistant is the only one I'm happy about.
Home Assistant (with all its dumb quirks) at least makes an attempt to integrate them. Some FOSS devices I've exposed to HomeKit for presence automation, but seeing Siri is going nowhere I don't think I'll continue.
> So many kids learn 4 years of algebra without having the slightest clue that this all is building to something called "Calculus" that they don't understand what it is.
That specifically at least could be improved greatly by just reworking classes to include plenty of hands-on practical application so it’s not so abstract. The pervasive thought during that period of my life was, “why am I learning this” and nobody wanted to bother answering except with the non-answer, “you might need it someday.”
Yeah the focus really should be on multipliers. Is it a clean multiple of the typical “normal” DPI resolution for that screen size? You’ve got a great screen. No? It’s a compromise. Simple.
1.5x looks ok mostly (though fractional pixels can cause issues in a few circumstances), but across platforms nothing is handled as well as 2x, 3x, etc is. I have a 1.5x laptop and wish it were either 1x or 2x.
The appropriate display scaling multiplier for this screen is 200% (2x), which is exactly why I regarded it pretty much clearing even this bar. On Windows at least, you can only alter display scaling in 25% increments (this is also why application designers are requested to only feature display elements with pixel dimensions that are cleanly divisible by 4), and so the closest fit for this laptop's PPI will be exactly the 200% preset option.
Using a lower preset than this is trading PPI for screen real estate. I don't think that's reasonable to introduce into the equation here. Yes, you match the relative size of display elements by virtue of (potentially!) being closer to the screen, but in turn you put more of the screen into your periphery, just like with a monitor or a TV. I don't think that's a fair comparison at all. An immersive distance (40° hfov) for this display is at 37.1 cm (a foot and a bit) - I think that's about as close as one gets to their laptops typically already. This is pretty much the same field of view you'd ideally have at your monitor and TV too, so either you use this same preset on all of them, or we're not comparing apples to apples. Or you just really like to get closer to your laptop specifically, I suppose.
Nah, look at laptop norms for the last decade and it’s clearly targeting 1.5×, not 2×. Even more so given how small it is: you’ll aim for a lower scaling factor because otherwise you can’t fit anything on the screen.
Some low hanging fruit for reducing app package sizes that tends to be neglected is just going through your dependencies and dropping the ones you don’t need and replacing those with unreasonable file size.
I forget which it was but years ago there was a common customer service library that a lot of apps include that on its own added like 25MB to your app package size. That’s insane, I’ve built and shipped full apps that aren’t that large. Adding that library would’ve over doubled size for questionable utility.
It doesn’t take dropping too many dependencies like that to reduce package size significantly.
reply