Hacker Newsnew | past | comments | ask | show | jobs | submit | Fwirt's commentslogin

Not only that, but why buy diamonds when Moissanite exists? Not as hard as diamond (by a tiny amount) but much less brittle and much more sparkle. Also even more “rare” than diamond since the only natural occurring ones are microscopic. Plus they come in colors! It took a while to talk my wife down off of the diamond industry’s hype, but she loves lab grown stones now.

I've been daily-driving a Planck with a custom layout for years now. I developed my own layout (QWERTY based but with punctuation and function keys on thumb-driven layers) and it took me a few weeks to get speed parity with my old 104 key, which was rough. But now I can't go back to a standard layout, it's just so much less hand movement that it feels so much better to type on. For gaming it's still a tossup, as most games expect you to have all the same keys in the same places. I've experimented with a "gaming" layer, but lacking a 5th row on the Planck still causes issues with some games.

It still baffles me that the standard layout isn't ortholinear after all these years. There's no reason for staggered rows other than path dependence. But when you have billions of people relying on years of muscle memory on the same layout, it's just not a tradeoff most people are willing to make.


Touch screens don't have to be modal, that's a UI choice. The 2020 Bolt we just got leaves the climate controls on screen at all times, even when CarPlay is open. I was also pleasantly surprised by the number of buttons it has, including both a volume knob and a temperature knob.

That being said, the touchscreen software is abysmal and laggy. CarPlay works great, but any time I have to navigate the car's built-in software is a headache.


> The 2020 Bolt we just got leaves the climate controls on screen at all times

At that point though they might as well be physical buttons! It's all the disadvantages of a touch screen and none of the advantages.


Actually it's an odd split. The temperature and fan adjustment are physical buttons, but the A/C, recirculation, and heated seat controls are on the screen. I'm thinking this is for two reasons: If a lower trim level lacks heated seats then they just exclude them from the firmware, and the AC and recirc controls require lighted indicators, which is probably a lot more expensive than just a button, so those were much cheaper to integrate into the display. That being said, I've heard digitizer failures can be an issue on this model so I dread that happening.

It also irritates me that there are 3 of those blank button placeholders on the dash and I wish they were actual buttons that were just mapped to A/C and recirc...


What I’ve always wished is that I could take pictures with a nice DLSR or bridge camera and have a way to quickly load the RAWs into my phone for culling and processing. You could get the best of both worlds, better sensors and lenses, and simple developing within seconds. I know there are cameras with built-in WiFi that do this but camera manufacturers seem to let their software become outdated quickly.


What I’ve always wished is that I could take pictures with a nice DLSR or bridge camera and have a way to quickly load the RAWs into my phone for culling and processing.

Apple makes (made?) an SD Card to lightning dongle. It's a wonderful thing on vacations.

I can take the SD Card from my Hasselblad and plug it into my iPhone. I then delete photos and videos I don't want, upload the keepers to iCloud as a backup, and AirDrop pictures to my wife so she can send them to her friends.

iOS has no problem with most current raw formats, and you can even convert them to JPEGs right in the phone.

You can also import the raw images and do basic editing of the photos with the Photos app.

The only problem I've run into is with long videos sometimes being laggy. But that might be an issue with a slow card, or moving data over a Lightning interface.


Since the dawn of USB-C iOS devices (iPhone 15 onwards), you can plug any old usb card reader into an iPhone or iPad without an adapter and it works.


The WiFi in cameras is definitively in the "do not use" category. It's usually some kind of flaky, broken, and/or slow.

I wish camera manufacturers just used Android on their devices, with possibly 5G for geotagging and time sync. It would immediately solve all the connectivity issues.


When is the last time you purchased a camera and how much did you spend? I am happy with the wireless performance of my Sony A7 SIII. I kind of splurged on it as my once in every 2 decades camera so I don't have anything to compare to besides connectivity first cameras (Drone).


I have a Sony A7 from 2019. I also tried a couple of other newer cameras from Nikon and one from Fujitsu.


It’s exploiting the natural tendency of trees to create “waterspouts” through a technique called pollarding. When a tree suffers an injury it creates a bunch of new twigs that tend to grow straight upwards if the injury is on the upper branches. The waterspouts grow more slowly and so in this species of cedar they develop those desirable properties.


It is actually a type of cypress, not a cedar.


I started writing a more fleshed out vi compatibility mode for TextAdept earlier this year. As someone who understood the basics after going through :vimtutor multiple times but always struggled with the more "advanced" commands, there's no better way to actually grok vi than to just try to recreate it. It's pretty amazing how much Bill Joy managed to pack in. Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing, but there are also quite a few commands that I had never paid attention to (like _) that have subtle behaviors that sped up my editing even more. The hardest part about becoming proficient in vi is committing commands to muscle memory so you don't habitually fall back on hjkl.


> Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing

What do you mean by "roff/troff macros"?

EDIT: Ah, you're probably talking about the "section-wise" movements, defined in POSIX with language like "A line whose first character is a <period> and whose second and third characters match a two-character pair in the 'sections' edit option (see ex)" - that's the first time I've stumbled upon the 'sections' and 'paragraphs' options in the Vim manual ... Very quaint!


Yep, those are the ones! There's also the oddity of the [[ and ]] motions. In the POSIX standard, those are the only two-character motions. I was using a state-machine to implement motion commands, and that single command threw a wrench in the works. Of course, vim took two character commands and ran with it, so in vim [ can be followed by a whole host of characters that all do different things. Since g was not mapped in vi they also did the same thing there.


It's a shame that, being based on a full-blown Linux SBPC, it has an absolutely unacceptable boot time for a camera. 22 seconds. I can have my iPhone camera out and ready to capture an ephemeral moment of child's play in under 3 seconds, most commercial cameras boot in seconds as well. A film camera can be ready to go the second the lens cap is off. 22 seconds is an eternity in the world of photography. It's a shame that the SoC the Raspberry Pi line is based on has no kernel support (or IIRC hardware support) for S3 or anything similar.


It's unfair to compare an idling deep sleep device with a cold boot.

However, there is a shortcut: Just don't boot a full OS (thinking of custom firmware which boots in fractions of seconds, standard in the Microcontroller world). Or boot an optimized Linux user space. I am confident with a bit fiddling one can bring down a standard SBC Linux to a few seconds from cold to ready.


Functional comparisons among devices within a category are always fair. Pointing out a device’s perceived shortcomings is not an attack on the people that made it. One crucial role designers play (ideally) in product development is seeking out honest feedback, filtering it, and figuring out if that feedback can help make the product better for end users. The FOSS landscape needs a lot more of that.


> Functional comparisons among devices within a category are always fair

When they have the same prerequisites, yes. But then you need to count in the time the iPhone needs to boot as well, which will probably mean you are at a similar range.


No, because the criteria here is state transition from not-in-use/power saving to in-use/"on". The Pi Zero has no meaningful sleep state, as I lamented above, thus the only valid "off-on" state transition for the Optocam Zero is a full boot. Sure, if you were to leave it on in your bag then there's no boot time, but then you're limited to 70-80 minutes of runtime. Then you get "instant-on", but you're limited to the photos you can take within an hour off the charger, which also renders it useless as a camera, and compares unfavorably to the iPhone . If it had a sleep state then we could compare apples to apples. Since the iPhone's default "off" state is sleep, that's what counts for "turning it on".


You don’t even need to technically justify the comparison. Apples and oranges can be compared if you’re discussing how useful each is for a particular purpose or in a particular context. Oranges are nice because the skin proffers protection from soil and bumps during travel. Apples are nice because you don’t have to peel them or deal with sections — you just bite hunks off of it. If you’re not throwing it in your bag, the shortcomings of the Apple might be totally irrelevant. If you’re going on a picnic, the convenience of the Apple might be less important. Similarly, it wouldn’t make much sense to abstractly compare whether moving trucks or motorcycles are better. It makes complete sense to say one has better cargo capacity, and one is way more fun to operate.


Ok, now read the other three sentences that explain why I said that.


>It's unfair to compare an idling deep sleep device with a cold boot.

Sure. My Fuji X100 is ready to shoot in about a second after a battery swap.


You turn a dedicated camera on as you grab it, cold boot, and most of them will be functional before you manage to put your eye to the visor.


There have been attempts to make the Pi boot faster (by disabling the initialization of various subsystems), e.g.:

https://github.com/IronOxidizer/instant-pi

https://himeshp.blogspot.com/2018/08/fast-boot-with-raspberr...

https://kittenlabs.de/blog/2024/09/01/extreme-pi-boot-optimi... (previously featured here too https://news.ycombinator.com/item?id=41420597)


i built my own camera out of a Zero 2W [0] and by disabling Picam2 and letting the OS (Debian Bullseye) idle, i can get 2 days of shots and some videos while i walk around the city/hiking out of 3 18650 batteries... bringing 3 spare batteries in my backpack never put me needing battery in any situation! starting Picam2 takes a fraction of a second

[0] https://happort.org/camera


https://mitxela.com/projects/thermal_paper_polaroid talks about making a camera with a raspberry pi, and by using Buildroot they got it down to acceptable boot times


Things lost to time: The Minolta Dimage A1 had contacts for detecting when gripped, so it could ready itself without any button pressed: https://en.wikipedia.org/wiki/Minolta_Dimage_A1 (You see it in the pic, but its not described in the article).


The early Sony Alpha A7 cameras run Android (really: you could jailbreak and write your own PlayMemories apps)

https://github.com/ma1co/sony-pmca-re

https://photo.stackexchange.com/questions/59226/does-the-son...

So there must have been a way to do this at that time. (I suspect a simpler subsystem does initial boot response).

I did contemplate building something around one of the Arducam modules and an RP2350.


They always ran Linux and Sony ported AOSP userland to it. So it's slightly different to real Android, and those cameras are not always in that mode.


> So there must have been a way to do this at that time. (I suspect a simpler subsystem does initial boot response).

They heavily use suspend-to-flash.


Comparing that to a real camera: I can "quick draw" pick up a Nikon DSLR that's off, flick the power switch and hit the shutter button one handed in one motion as fast as I can move and there's a good picture on the screen as soon as I let go of the trigger. Double click trash can and it's gone. Either will take less than half a second. Battery life is so long I usually forget to charge it. I suspect the power switch is just a "key lock" that prevents triggering anything because there's no delay. Either that or it's a wakeup in the microcontroller range of timing.

(You can easily get jank by filling up the buffer or slow memory card or autofocusing on something impossible, possibly in the dark etc, of course.)


My kid has a Fisher-Price Kid Tough camera. It's excellent for us but the pictures are so bad even the kid is disappointed.

It would be fun to repace the guts with something like this project but a long boot time is a deal breaker.

Perhaps the software can be optimised or a DIY friendly pi pico project is the way.


It’s possible to boot Linux in seconds, it’d just be a terrible developer experience.


The problem is RPi though, and all the junk it runs before booting Linux.


I bet this could be changed to seconds if a unikernel type approach were used. There’s no need to boot a full OS. I understand the developer starting with Linux, though, as I’m sure it’s easier for debugging.


you can get a zero booting under 10 seconds fairly reliably.

still slower than a hot phone with an app, but it's faster than 22s.


Sub 2-second booting Linux is generally possible, either by bundling everything into a big image or by creating a fixed hibernation file and resuming from it. That's what they do for real embedded systems, but the downside is that they tend to be monolithic and not so update or modding friendly.

1: https://www.youtube.com/watch?v=TTcP3xeLrEY


Not from off state, though? Granted I still expect the iphone to boot quicker than 20 seconds.


yeah it's pretty fair if you compare them apples to apples.

an iphone boots in 15-20s depending on how stale things are, you'll presumably need to unlock it, and then navigate to the camera app however you do so.

it's just presumed you wont have to boot your phone.


I agree with the premise but that's a bad comparison. If you have your iphone off, do you get to the camera in 3 seconds as well, after booting?


Nice, my Google 10 I feel boots rather fast but I'd say 5sec to boot, unlock, camera +5 secs so it would be 10 for me - 3 seconds I envy you.


Cameras shouldn't need to boot at all.


Pretty much everything has a boot sequence of some kind, it just might be very quick.


The point they were trying to make was that if you take appreciation of assets into account, if your billion is appreciating by a relatively modest 5% per year, you are passively earning 50 million/year. Whereas someone with one million passively earns 50 thousand/year. One is enough to live in luxury anywhere in the world for several lifetimes, the other is enough to live comfortably in some parts of the US (or like a king in many parts of the world) but not enough to throw 6 figures at a programming language foundation for fun.


This is a common but silly claim; there is, generally speaking, no such thing as a safe rate of return that overcomes the inherent losses due to inflation. If you're getting a 5% rate of return on cash, that comes with both risk (someone with a billion dollars isn't going to benefit from FDIC insurance) and doesn't even overcome basic inflation.

That $50 million a year is also subject to income taxation and cannot be easily avoided. $50 million a year in interest on returns from cash will be hit at the 37% marginal rate, plus whatever the state assesses, so north of 50% in California.


Or to take an intermediate value, $10 million is 500k a year and most people will find it difficult to spend that much on themselves, so it’s going to grow on its own and compound. It will grow more rapidly if some is invested in the stock market.

Also, donating appreciated stock avoids taxes. This donation may have come out of a donor-advised fund.

Rich people can make substantial charitable donations rather easily and make a big difference. I suggest we encourage them.


Thanks, that is much clearer than my wording.


We just bought our first (used) EV, and charging stations are the Wild West right now. Any random station you pull up to might charge close to the local cost of electricity, or some wild sky-high amount. And hopefully they’ll tell you what that is before you have to swipe your card. There the economics can swing towards gas cars depending on how absurd your local charging station prices are. For people filling their tank every couple days because of a 2 hour commute or something an EV may still not make sense financially. But if you’re putting in under 40 miles and have even a modest 120v 12 amp circuit you can plug into at home (e.g. a dedicated washing machine circuit) you’ll likely only need a charging station on rare occasions such as a road trip. As a matter of fact I am writing this from our first EV road trip. The inconvenience has been comparatively minor and our “fuel” costs should end up being about half of what they would have been in our hybrid SUV.


The Toyota Prius and the Rav hybrids are popular for many of the reasons you mentioned.


I'm sure the idea here was a physical quine, although since it only contains 2.5% of its own G-code it's not really a quine, any more than a "Hello World" program is a quine since the string "Hello World" is in the program text. It would be trivial to generate something like this depending on which part of the G-code you pick.


Many G-code dialects contain subprogram calls, loops, and conditionals that seem like they'd permit a physical quine. The standard RepRap firmware breaks the rules by taking input:

https://reprap.org/wiki/G-code#M98:_Call_Macro.2FSubprogram

but Fanuc and other dialects allow M97 to call a subroutine chained to the end of a program.


G-code is like assembly language for CNC. It’s human readable, you can write it by hand if necessary, most machines will compile it internally to machine instructions, and there are a million different flavors with incompatible macros, etc. The flavor I’m most familiar with is Klipper’s interpreter, which will let you write macros, but that would technically be cheating since you could just stuff an entire program into a macro.


For anyone thinking of this, I promise to be suitably impressed (defined as "upvoting it when I see it on Hacker News") if anyone does manage to get a true G-code quine in this sense. Go for it.


It's not cheating if you print both.


I work a lot with Aerotech's Aerobasic which is G code mixed with a basic like language. You can generate G code on the fly and execute it, manipulate files, call other programs, text boxes, menu boxes, etc.

I wrote a simple teach mode program that puts the machine into jog mode where you move the axes around and create points and associate a command for each, e.g. G0 rapid, G1 coordinated, G2 clockwise arc, G3 counterclockwise arc. Each move is then written to a file that is saved and loaded afterward for testing. Nice system but very costly.


pretty sure I'm a physical quine


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: