I believe solar carports of that size need to be constructed with steel, and South Korea has a significant steel oversupply issue now, so this provides a way to keep the industry going.
I think Mr Bradbury would remind you his book was about how passive entertainment (the "parlor") slowly eroded books for decades before the actual book burnings, not the state just suddenly banning them.
In that sense, I suppose you could still make it work. Our society celebrated surrendering ownership of media to iTunes and Steam for our convenience, whittled down online content that didn't make us feel good, limited which applications we could install on our phones in the name of security and privacy, and eliminated our anonymity to save the kids. At this point, removing the hardware is the least surprising step, because as Captain Beatty says, "if you don’t want a house built, hide the nails and wood."
For some projects, the issue tracker is a pretty integral part of the documentation. Sure, you can host your own issue tracker somewhere, but that's still shifting a center point somewhere, in a theoretically decentralized system. I've frequently wished the issue tracker was part of the repository. Also -- love them or hate them -- LLMs would probably love that too.
Years ago when the ARM China CEO held the company hostage with the company seal, there was much reporting that exoticized seals. But I was just thinking, the modern systems we've built with 2FA aren't much different!
(Product idea: seal that also prints time and TOTP?)
Without commenting on any other part of this exciting console war, I don't know if this is true. Steam on my machine still always consumes nonzero CPU when minimized, possibly because it opens to the busy animation/video-filled front page then its WebView doesn't detect minimization. It's funny how Steam never comes up in the "stop making WebView/Electron apps" discussion when they were the original sinner (yes I know they were using IE originally).
Some of Mozilla's positions are based on Apple's, such as the refusal to implement Web NFC [0].
Since Webkit has been the only engine allowed on iOS, ultimately this is a disagreement on app distribution. I can see Apple and Mozilla's argument regarding Web NFC, but I also don't want to write a whole app so my friends and I can play around with NFC tags. I find it irresistible to draw comparisons to the new Android situation regarding non-Play Store apps. If there was a developer registration list for websites (that was better than DNS registrar records and TLS certificates), would Apple and Mozilla find that acceptable? After all, I need to give my real name and payment details to Apple just to write an app.
But for good measure I will add one for Mozilla too. Firefox Android still doesn't support the Web Codecs API [1], so I need to use the "jpeg" codec on Selkies remote desktop sites, which I assume is rather poor for my bandwidth and battery.
And chrome still does not support plugins on android, to my great surprise, while Safari has them on iOS. I honestly much rather have plugins than web nfc, or whatever the chrome bully decide should go in a browser.
Google’s choice to exclude extension support on Android can’t be a coincidence. Great example of conflict of interest with a web ad giant running a web browser.
It doesn't have to be an either/or situation and I certainly want both in my mobile browser!
Ad hominem is also not a valid argument against NFC. One of my friends built a whole automatic mahjong table with NFC tags. NFC apps are used in access control for offices, college dorms, apartment complexes. Businesses have obvious use cases for it, from inventory management to payments. Governments want to use NFC for government functions and visitor prearrival processing. Sure, maybe some of them want you to install apps for other reasons, but I can assure you not all of them do, so it's a shame that this function is so exclusive.
I think western users using NFC for payment, transit, gym access, etc. are not aware how apathetic the rest of the world would be if phones start taking out NFC, and one of the ultimate causes is that it's so difficult to work with across all users. It's just so much easier to make a website that shows a QR code that your PoS system or gym access gate can scan. Bottom of the barrel Android phones in India and China already ditched it and that's just going to exacerbate the issue. If it goes the way of the 3.5mm and microSD card in the next decade, we can put this in its autopsy report.
Not a kid but what are the next steps after this book? I've been trying to find the steps of the ladder between "playing with muxes and clocks" and "designing a USB3 peripheral", but that has been a challenge in itself.
Don't wish to write my usual rant on this here but that's the curse of electronics books. You get taught by a recipe book but you don't leave with enough skills to design your own one. Nor do you know which recipes should be served together. It requires a much lower level of understanding and that is hard.
I got taught via recipe books then studied EE at university and had to throw everything away. Then I started in industry and had to throw that away again. There's a huge moat between the two ends.
Make 5-10 of multivibrators each on different schemeatics. Bonus point - make them as fast as you can - starting from the prototyping stage and finishing with the device ready to be either gifted or used as a lab generator.
But playing with clocks and multiplexer is definitely not a beginning of the ladder.
Yeah, it seems clocks and muxes is what comes after this book? A possibly not so great suggestion is building a radio(receiver)? It is pretty challenging with oscillators, tuned circuits, mixers, amplifiers (basically a mix of RF, AC and DC).
They were one of the few distros at the time which had a sane out-of-the-box desktop experience for non-tech people, back when Ubuntu was pushing (the original) Unity and GNOME was still the the early days of 3.x. Drivers and codecs were easy to install as well, generally speaking, without having to hit the forums or ask your tech family member for help.
Maybe we're not going to the same places but "just having a website for rates and hours" is a SAT problem for salons/tattoo parlors. They need to know what you want and also show flattering photos of what they can do (and also comply with the growing mountain of privacy regulations), determine if you have any staff preferences and when staff is available for whatever you're requesting, and compute the available times grid. If you just want a speedcut, that's not necessarily what those shops are optimizing for.
Even if they have the tech from an existing SaaS solution or from vibe coding, they still gotta diligently update the source data from staff. You can't blame anyone for giving up, posting their phone number and a few pictures on social media, and just writing reservations down on paper.
I really thought the article was about personal websites like in the 90s, not bringing up hair salons as an example.
A hair salon needs a presence on Google maps with a bunch of reviews and their rates and that's it. Sure they don't own it but until that works it works.
Locally I have an issue finding builders and electricians, because they don't have websites. They may have a listing in the phone book, but that's just "Bob's bricklaying", doesn't tell me a lot about whether or not Bob is actually a company, but I can call and ask. Sometimes they haven't had a company for years.
The preferred methods today seems to be Facebook for your average builder, Instagram if they feel like they do more upscale work. I'm on neither platform, so I have to resort to taking pictures of vans when I'm out and about.
I think the problem is that having a website is a bit complicated for a carpenter, but not enough business for a webdesign company to deal with.
Your ratio idea presumes a lot about the maintainers or the nature of the disagreements. I recently sent a handwritten PR to fix a bug in a well-respected project, which involved switching from API A to B. The maintainer was uncomfortable with using B (although I had tested it) and suggested that I call A in a loop, which seemed more dangerous to me. In the end my PR was closed and the bug is still somewhat unresolved.
Should that affect our hiring? In an ideal world, no. He had his opinion and I have mine, and I do reflect that I should've asked if I could've added integration testing to assuage his fears regarding B.
The real problem is the fact that we as an industry have celebrated using casual volunteer work as a hiring indicator and devalued our own labor to a degree unseen anywhere else. The GitHub activity grid turned us all into cattle and should be seen as a paramount violation of ethics amongst the invention of leaded gas and the VW emissions scandal.
reply