Hacker News new | past | comments | ask | show | jobs | submit | 2ton_jeff's comments login

One of the things that actually sold me aside from the repairability thing and all was their wikipedia page[0] where it says that "HMD is headquartered in Espoo, Finland, and is largely run by former Nokia executives."

I was rather hoping that it'd be more like the Nokia we all remember from pre-iPhones. Guess not.

[0] https://en.wikipedia.org/wiki/HMD_Global?useskin=vector


It's basically an attempt to capitalize on the goodwill of the old Nokia. Headline products are nostalgia-fuelled feature phone remakes. Their Android lineup is indeed very meh.

Pretty similar to the "new" Atari.


Bought it online directly from Nokia, though it came from their partner Ingram Micro.


First, tell Nokia you intend to contact the ACCC about this refund, as the device isn't "fit for purpose" if it can't store files greater than 4GB.

If they don't instantly change their tone (as many vendors do once you mention certain four-letter agencies like ACCC or ACMA...), then lodge a complaint with the ACCC.

Ingram in this case are just acting as a warehouse/drop-shipper, same as they do for Microsoft and various other OEMs.

... although our (Australias) Data Retention and 'Lawful Access' legislation is crap, at least the Consumer Guidelines still generally favour the public! :)


They have operations in Australia, so they'd be covered by Australian Consumer Law[0], which requires goods to be of "acceptable quality". IANAL, but I think you should have a good claim under that given most other phones support exFAT, and the deficiencies with FAT32.

[0]: https://www.accc.gov.au/consumers/buying-products-and-servic...


A couple of years ago I did a "Terminal Video Series" segment that also highlights the runtime overhead of 12 other languages, C of course actually one of the best ones: https://2ton.com.au/videos/tvs_part1/


I was actually surprised for C how expensive that is, I'd expected maybe a dozen or so syscalls to set up the environment the provided runtime wants, but that's a lot of syscalls for not very much value. Both C++ and Rust are more expensive but they're setting up lots of stuff I might use in real programs, even if it's wasted for printing "hello" - but what on Earth can C need all those calls for when the C runtime environment is so impoverished anyway?

Go was surprising to me in the opposite direction, they're setting up a pretty nice hosted environment, and they're not using many instructions or system calls to do that compared to languages that would say they're much more focused on performance. I'd have expected to find it closer to Perl or something, and it's really much lighter.


glibc isn't particularly optimized for startup-time. It also defaults to dynamic linkage which adds several syscalls, and even if it is statically linked, it may dynamically load NSS plugins. (musl gets around the latter by hardcoding support for NSCD, a service that can cache the NSS results).

C11 adds several things that benefit from early initialization (like everything around threads), but GCC had some level of support for most of them before that.


I routinely don't want persistent mount points. Imagine my: cryptsetup luksOpen /dev/sdXY name Followed by: mkdir -pv /dev/shm/name mount -o noatime /dev/mapper/name /dev/shm/name

What this "RemoveIPC" did for me was rm -rf all of that, even if I mounted them as root.

That a single "RemoveIPC" difference between openSUSE 15.2 and 15.3, undocumented, caused me to lose all that data is one thing.

Another thing entirely to question WHY "RemoveIPC" is even a thing to begin with. I have never logged into any machine and said "wow look at all of this stale data taking up RAM in /dev/shm".


In fairness, that history seems to indicate that maybe it really was SUSE who decided to enable it. Sure seems like "RemoveIPC" option should have been advertised as a 15.2 -> 15.3 update repercussion. :-( :-( Leap 15.2 didn't do that, 15.3 does. Unknown what the other systemd distros do with "POSIX shared memory cleanup"


15.2 -> 15.3 included a systemd version update.


Flat Assembler is actually easier to get your head around early on than any of the *asm variants IMO: https://flatassembler.net/


I also learned Z80 first, and I can say categorically that learning 16-bit x86 is NOT a good idea. To do anything useful in 16-bit, register starvation is a constant. Segmentation issues are actually hard problems.

I submit that if x64 existed early-on, no one would have bothered with higher-level abstractions. x64 is actually -pleasant- to code in natively.


I wrote a Linux general purpose library for x64 assembler: https://2ton.com.au/HeavyThing/ and in recent months I decided to start doing video tutorials about the "how and why" of same. Learning I think is made easiest in Linux by learning how to navigate the syscall interface and how "man 2 write" becomes an important skill. Edit: Videos link as well: https://2ton.com.au/videos/


Obligatory addition of the assembly language TetrOS in a single boot sector (512 bytes) from the author of flat assembler many years ago

https://twitter.com/grysztar/status/1054729111623606273


Real demoscene material, right there.

And to think Super Mario 64 was a whole 8MB.


probably should have titled it "now" instead of 09:00 UTC, apologies.


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

Search: