Hacker News new | past | comments | ask | show | jobs | submit | unusual-name's comments login

I used to use Thoughbooks every day at work while I was working as an EMT. I kinda have a love/hate relationship with them. I loved their ruggedness. They can fall from the stretcher to the ground, you can sit on them and they even work when it's raining on them. But everything else is not that great. The keyboard feels awful, the touchscreen sometimes didn't work (which was awful because the application was designed for touchscreens) and the trackpad is tiny compared to other laptops. Still they're better than the alternatives that other cities used. Documenting with pen and paper is exhausting, iPad aren't as rugged and their on screen keyboard is even worse and smartphones just don't appear that professional.


We had toughbooks at my agency, that were then replaced by surface (non-pro) tablets when we got bought out by AMR. They had to put out notices not to set the tablets on the back of the gurney. I bent one into a U shape with the strut lowering the head for a bariatric patient. Smushed it right between the monitor and O2. It was the most annoying piece of gear we had. Went from not having to worry about your computer at all to having to baby it. I wouldn’t be surprised if they cost more in the long run.

The AMR software, MEDS, was also worse as it forced you to use their limited fields instead of a full written narrative, surely for better analytics. The previous software (zoll?) made it much easier to rely on the narrative to accurately note that the patient who called for chest pain just had bronchitis, even with a primary complaint of chest pain. Practically a daily call in the winter, and a super annoying chart to write with MEDS while trying to cover yourself as a basic. The only advantage of MEDS was that since it was all radio buttons you could just spam tab>space to fill out almost the entire chart for your average patient.


> The keyboard feels awful

So sad. I had a Toughbook CF-30 and its keyboard was one of the best I ever used on a laptop. Not mechanical, but it had a bounce to it that made it easy to type for a long time without getting tired.

In the next iteration (CF-31), they changed it to a chicklet style keyboard like those common on laptops nowadays, and there was no magic anymore.

Another think I loved about my CF-30 was how bright the screen could get.

Agree on the trackpad, that thing was small and never worked right.


Use fingernails. It's resistive touchscreen similar to Nintendo DS and pre-iPhone smartphone, without the screen part.


The backlit keyboard is compatible with the 30 and 31, and is what you are looking for.


100% better than the GETACs my ambulance service used, those were hot garbage, with even worse touchscreens (or it may also have been that my service was so cheap they'd buy them on eBay, and even buy partially broken ones and the Director of Ops would Frankenstein multiple broken ones together to get one working)...


I used both, but the thoughbook with Windows and the GETAC with Android. The touchscreen experience was much better in the GETACs I used. The thoughbook is good in the laptop format as linked but not the thoughbooks that are meant to be used as tablets - those die easier.


Do you think the keyboard is awful because it needs to survive incredible abuse and operating conditions (liquid spills, etc)?


-Probably, there's a (at least used to be) rubber membrane between key caps and switches to ensure water, coffee, hydraulic fluid, blood, assorted acids, dust, gravel etc. does not make it inside when you douse it in one or more of said substances.

(My last Dell Precision died after having been first on the accident site when a high-pressure manifold burst, courtesy of a sub-par weld - it sat merrily on a tank opposite, logging pressures, temperatures and contamination levels during an operation when suddenly, the manifold opted out of existence, blasted the Dell into the bulkhead, cracked the casing in so many places we didn't even find all the parts afterwards, dousing the remnants in hydraulic fluid (which, as it happens, is quite corrosive and reasonably carcinogenic, too.)

Had a similar thing happen to a ToughBook years later. Simply donned gloves, took it outside, hosed it down in lukewarm water for a while, rebooted and got back to work.

For all their shortcomings, ToughBooks are amazing at their intended use case.

(Oh, and before anyone asks - we set up the test rig, make ourselves scarce, and only then do we start the pumps and apply pressure. I am a firm believer in staying alive.)


Germany wants to strengthen their game industry by giving grants to game developers. Since 2019, 550 projects were partly funded by the government. [1]

[1] https://www.bmwk.de/Redaktion/EN/Dossier/games.html


It depends on the implementation. For example, jemalloc can use sbrk(), sbrk() and mmap() or just mmap(), depending on what your os supports.


Apparently the CPU in this SBC violates the RISC-V ISA pretty badly. [1]

[1] https://lore.kernel.org/all/CA++6G0Do001Bo+kxhUNz5T937TYU-K5...


Keep in mind the spec being violated is the privileged spec, not the core instruction set (which is what people think of when they think of an ISA violation). Personally, I think the privileged spec is a little too overzealous about the implementation-specific details that it specifies, and a little more should have been left to chip vendors.


For the uninitiated, what kind of things? I mean are these things that are necessary for desktop operating systems, but overkill when used as a DSP or something like that? I mean these aren't dumb people working on this so I wonder what this trade-off is.


Exactly that - they specify things that you need for an OS on a desktop/server system but complete overkill for embedded applications. I think the goal was to have one version of "RISC-V Linux" without vendor-specific extensions, but the chip vendors are used to their extensions, and there are good reasons to allow them to have some more customization (to allow design tradeoffs).

Also, in the ARM ecosystem, some of the things that the RISC-V spec specifies (like MMU details) are vendor-specific, leading to a minor headache for OS writers, but give chip manufacturers more freedom. Renesas may have assumed they had the same freedom.


The Arm ecosystem is a shitshow for this reason, with massive efforts required to port to each new SBC. We hope to standardize RISC-V enough to avoid at least the worst of this (Linux drivers will still be a problem, but you should be able to boot a standard single image on most boards even if some of the hardware won't always work at the start).


So this sounds like a deliberate design choice. Like when Intel went from pins to balls shifting the complexity to the motherboard. There are always trade-offs. I guess the idea is that the overhead is worth the benefit to the ecosystem and if the vendor really needs to they can create a chip that is only conformant at a user level but not at a priveledged level and still better than starting a custom ISA from scratch.


On the other hand, it sounds from the thread like the result of the deviation from the spec is "you can't run userspace binaries unless you built them with a binutils that's working around this", so it's not just a "weirdness the kernel has to deal with" kind of thing.


If everyone is understanding it correctly then that appears to be the case. Apparently user-space addresses from 0x20000 to 0x3ffff are not mapped by the MMU in the expected way, but are directly mapped to the same SRAM for every program.

A statically linked "HelloWorld" on my VisionFive 2 starts from 0x10000 and runs up to 0x4ea8e, so smack through that whole memory region.

The only way to make programs compiled with a standard binutils (or on another RISC-V machine, or a standard OS running in a VM) work would be for the kernel to memcpy() that 128k region in and out on every address space switch.

It's really an awful bug (or design decision) if you want to run standard OSes and standard code on it.


On the other hand, the privileged spec is also designed to provide process isolation and other security features. It may not seem as drastic as if a core instruction were misinterpreted, but this is IMO not the layer you want unexpected deviations from spec in.


Why does the ISA spec define the starting adress of the text segment anyway? Struggling to find a good reason.


It doesn't. Effectively the architecture spec defines behaviour so that it shouldn't matter what you choose for the text segment starting address, but this implementation's non-standard behaviour means it does matter, because there's a weirdly behaving address range you have to avoid.


It doesn't.

This implementation has a very incompatible (and problematic) deviation from the privileged ISA spec.

It seems to act as if there was a hardcoded, stuck, TLB entry that cannot be removed, so the whole system has to work around it. And to add insult to injury, it affects a virtual memory address range that happens to be used in most Linux programs.

IMHO ASUS is doing a disservice to RISC-V by releasing a board with such a chip. They should have used something else or skipped this generation.


EUPL is approved by the OSI and the FSF


You are right, I stand corrected.


I might be wrong, but I think it’s Excalidraw: https://excalidraw.com/


yes, I used excalidraw!



You're right, I forgot about this one. I think because when I last looked at it, the MVCC part wasn't very straightforward to me.


I think the main difference is that this is for Linux and MacOS and not for Windows


The sentence at the very top of the GH repo reads

> Virtual File System for Git: Enable Git at Enterprise Scale

Does it sound any similar to what this particular project tries to tackle?


No. VFS is for /the underlying git/ and not for the user (aka, the .git folder). The linked project is for the end user.


That was a rhetorical question.

I usually understand that people read mostly titles. It was a bit funny though that someone likely managed not to read both the posted site and a link in a comment they replied to.


The website is terrible. It neither really tells me what the product does, nor do I know now for who it is. And the fact that it is patented is irrelevant for the end user and I also don't always associate patented products with great products.


Thanks for the feedback, we will improve in upcoming days.


For gambling games you need a custom license, but other than that I don't think there are any other restrictions.


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

Search: