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

I pay $5 a month, and my company has a license for every employee.

> I make Vim colorschemes

Then you're not really covered by the article? A colorscheme is all about... color. A TUI is about the content and function. I think there's room to have user-defined 256 palettes that are used by default, while colorschemes can use true color and be chosen by the user if they desire.


Here's a direct link to the latest Veritasium. You're welcome!

https://www.youtube.com/watch?v=cMx139eTxoc


Fluffy Chat is great on iOS. My mom uses it; it respects system fonts very nicely.

I get the frustration with encryption though. I wish there was a way to mark a homeserver as default _NOT_ encrypted. My homeserver is in my closet. Given the choice, I'd rather take the extremely tiny opsec hit for all the simplicity and usability benefits of unencrypted rooms.


Keys are actually saved somewhere. On your homeserver, in a store itself encrypted by another key that only you (and your other clients) have.

You can disregard that store and not use it at all, which I actually think is a totally valid use case. It turns Signal-style at that point.


I just added search. ;)

https://github.com/pkulak/matui/releases/tag/v0.6.0

For encrypted rooms it just starts pulling messages down and looking for substrings... but it's actually works pretty well if you don't want to search back to the beginning of time.


cool! would be even cooler to hook it up to https://github.com/matrix-org/matrix-rust-sdk/issues/5350 when it should then just work?

matui looks super fun - you should come tell https://matrix.to/#/#twim:matrix.org about it :)


Oh, very nice! I'll absolutely hook into that once it's ready.

lol, is this serious? The final straw with Mac for me was when I accidentally hit “No” when asked if I wanted to give my terminal access to the file system. All of a sudden I was starting my work day without a working terminal. Obviously there was a solution, probably an easy one, but I didn’t even look for it.

> The final straw with Mac

> Obviously there was a solution, probably an easy one, but I didn’t even look for it

It's hard to take this seriously. It's the most obvious setting possible. Settings > Privacy & Security > Full Disk Access > tick the apps you want to have it.

What's even the complaint here? That Mac has solid app permissions, but you can't be bothered to open the settings?


I said it was likely an easy solution. Glad to see my intuition was correct!

I also said it was the “final straw”. No worries at all if you’re not familiar with that expression. It means that there were lots of similar slights previously, and that the event I mentioned, while minor, was the one that finally pushed me to make the decision I made.


> I also said it was the “final straw”. No worries at all if you’re not familiar with that expression. It means that there were lots of similar slights previously, and that the event I mentioned, while minor, was the one that finally pushed me to make the decision I made.

This sort of patronizing assholery is childish and unbecoming. Your comment would've been better without it.


My comment wouldn't exist without it.

> you can't be bothered to open the settings?

This kind of crap ticks me off and makes me respond in kind. I should be better, sure, but sometimes I'm not.


>> you can't be bothered to open the settings?

> This kind of crap ticks me off and makes me respond in kind. I should be better, sure, but sometimes I'm not.

I think we're all struggling to identify any other possible interpretation of, and I quote, "obviously there was a solution, probably an easy one, but I didn’t even look for it". Your words are not ambiguous - you knew this would be an easy issue to solve, and you did not bother trying to solve it. And you say this as though it's someone else's fault.

Should Tim Apple come to your desk personally every morning and ask which MacOS defaults it would suit you to remove? Are we to understand that the obvious security benefits of sandboxing filesystem access pale in comparison to any inconvenience for you, even if that inconvenience is you merely having to bother to open the settings?

You're being totally unreasonable, and you're acting mean when your unreasonableness is picked up on. Learn to take a note, particularly when you're in the wrong, rather than becoming an irrationally defensive ball of spittle and venom. It'll serve you better in the long run.


> Should Tim Apple come to your desk personally every morning and ask which MacOS defaults it would suit you to remove?

> rather than becoming an irrationally defensive ball of spittle and venom

Dude, maybe take your own advice?

I was possibly being too subtle, but my POINT is that MacOS has turned into a nanny state OS that is not suitable for professional use. You can't install packages that aren't from the App Store without jumping through hoops. And Gods help you if they aren't signed with a key blessed by Time Apple. You can't even use a terminal without granting is special permission. AGAIN, straw that broke the camel's back. You keep focusing on the straw and not the back of the poor camel.


The solution is to enable Full Disk Access in settings.

Are you sure? This felt like it was specific to iTerm. Like I’d have to scroll a list of apps, find it, and modify what it’s allowed to access.

If this is “on par” with LFP energy density, I’m not sure there’s any need for LFP now. Sodium ion seems to thoroughly beat it in every other metric.

On par on a per kg basis, but is it on par on a volume basis? If it takes up more space, that might pose packaging challenges relative to LFP.

Sodium has greater density than lithium, while most other materials used in a battery have similar densities regardless if sodium or lithium is used, so if a Na-ion battery and a LFP battery have about the same mass and stored energy, it is likely that the sodium-ion battery has a smaller volume.

that doesn't check out, capacity depends on surface area, if the element that is on the surface is heavier then, all other things equal, the battery will be heavier for same kWh.

Sodium would need to be more efficient to be lighter, which it isn't


The maximum deliverable power depends on electrode area, through the maximum current density.

The capacity of storing energy does not depend at all on area, but only on the mass of sodium contained in the battery and on the efficiency of using it (i.e. between full discharge and full charge not 100% of the sodium or lithium is cycled between the 2 oxidation states, but a fraction, e.g. 90%).

Any battery has both an energy density and a power density, which are weakly correlated and the correlation may have opposite signs, i.e. for some batteries it may be possible to increase the power density if the energy density is lowered and vice-versa.

For a given stored energy in kWh, the required mass of sodium is several times greater than the corresponding mass of lithium, by a factor that is the product of the atomic mass ratio with the ratio between the battery voltages. The voltages are similar, with a slight advantage for sodium, so the required mass of sodium is about 3 times the corresponding mass of lithium.

If the complete batteries have about the same mass, that means that other components of the sodium-ion battery are smaller and/or lighter.


Energy density of Na cells is lower, but it is the viable charge cycle count that is the show stopper issue for most markets. =3

They are also safer.

Na will be big in grid storage, it's a perfect fit.


It is all about cost and efficiency... There is a classic 1913 electric vehicle that ran NiFe packs for many years, and were only replaced because the container rotted away. Sustainable storage costs real money, but has existed for over a century. =3

https://www.veva.ca/1913detroitelectric

https://en.wikipedia.org/wiki/Nickel%E2%80%93iron_battery


I have no idea about the characteristics of these new sodium-ion batteries, but there is a great likelihood that they auto-discharge much faster than LFP batteries.

This means that if you do not use the car for some time, you may need to recharge it before you can use it again. This may be a problem if the car is left far from a charger.

Otherwise I agree with what you said.


citation needed

I haven’t seen any info on charging speed. Can you recharge these as quickly as LFP?

CATL's Naxtra cells apparently have a c rating of 5C. Which boils down to about 12 minutes for a full charge with the right charger. So, as fast or faster than LFP would be the answer here.

If they have a 5C rating from 0 to 100 that would be a real game changer. I look forward to the days we don't need caveats like "only up to 80%".

100% is a soft limit in many batteries. The battery management system actually prevents you from charging too much. Pushing it too far can damage the battery so they don't let you completely charge it.

A lot of EV drivers optimize to minimize waiting time. Mostly you try to charge while you are doing something else (sleeping, working, eating, shopping, etc.). So, you are not actually waiting for it and sitting in the car bored.

Charging speeds are non linear. The last few percent take a bit more waiting. But you don't actually have to charge the battery to 100% all the time. Two 10-80% charge breaks might be a lot less less time than one 10-100% charge break and it will get you a lot more miles.

When you are driving long distance, you can plan to top up while having breaks, lunch, etc. Just top it back up to whatever the time allows. You don't have to drive the battery to empty either. And destination charging is a thing as well.

You can trade off not having to stop for a bit more against the charging time. Charging to 100% at night is a good use of time. Because you are probably sleeping/resting. Interrupting your journey to do the same is probably not a great use of your time. Two 10-80% charge breaks might be a lot less less time than one 10-100% charge break and it will get you a lot more miles.

Of course on longer journeys, planning for 45 minute charging breaks is a lot more annoying than planning for 15 minute charging breaks. Which is what 5C charging should enable given the right cell and charger combination. With a normal EV (medium sized battery) that's once every 3-4 hours roughly. A bit longer if your car is more economical with the battery. That's actually not a horrible frequency for taking a short break. Even if you drive a petrol car.

And if you are really anxious about that, get an EV with a bigger battery. 300 miles. 400 miles. There are even some 500 mile batteries in some cars now. It will cost you of course. Financially it's probably not a great choice for most people.


Most people posting about 80% seem to talking about charging at home. If you are charging overnight, why are you restricting charge level if it doesn’t really matter to longevity? Is it just left over advice that no longer applies?

There’s this program on nix that lets you type a comma, then any application name that exists anywhere in the Nix repos. It then downloads that app and runs it once, without “installing” it. Sometimes I find myself running something dozens of times this way before I realize it should probably be in my config.


I'm not sure I'll ever understand why they replaced their working ~50 line shell script with a Rust program that just shells out to the same nix-* commands. I appreciate that there are some safety benefits, but that program is just not complex enough to benefit.

Because it's "a proper language" [1]. Not to mention webscale!

It does seem to do some more complex stuff now that would've been annoying, but not impossible, to write as a shell script.

[1]: https://github.com/nix-community/comma/pull/19


Shell is already memory safe, so there's not even "we replaced C" to lean on.

Maybe it was fun?

Oh wow, just going into the "should I shutdown" menu also goes into pre-boot lock state? I didn't know that.


It doesn't reenter a BFU state, but it requires a passcode for the next unlock.


It's close enough, because (most of) the encryption keys are wiped from memory every time the device is locked, and this action makes the secure enclave require PIN authentication to release them again.


> It's close enough

Not really, because tools like Cellbrite are more limited with BFU, hence the manual informing LEO to keep (locked) devices charged, amd the countermeasures being iOS forcefully rebooting devices that have been locked for too long.


There is a way now to force BFU from a phone that is turned on, I can't remember the sequence


It’s called restarting the phone.


I believe doing the standard Restart everyone knows is not enough though. The instructions saw were these

Quick-press Volume Up, then Quick-press Volume Down. Hold the side power button until the screen turns black (approx. 10 seconds). Immediately hold both the side button and the Volume Down button for 5 seconds. Release the side button but continue holding the Volume Down button for another 10 seconds. The screen will remain black. If the Apple logo appears, the side button was held too long, and the process must be repeated.


That’s DFU mode. We are talking about BFU in this thread.


Eh? BFU ("before first unlock") is, by definition, the state that a phone is in when it is turned on. There's no need to "force" it.

If you mean forcing an iOS device out of BFU, that's impossible. The device's storage is encrypted using a key derived from the user's passcode. That key is only available once the user has unlocked the device once, using their passcode.


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

Search: