The points are good, but I certainly don’t want inotify features to be gating the VFS layer. IMO inotify is good at what it does. If you want to know about absolutely everything going on for a given filesystem, maybe you want to implement the filesystem itself (fuse, e.g.).

[Comment removed by author]

This is an interesting device in the era of smart phones. This is aimed at college students for particular exams. Are they not allowed to have their smart phones in these exams? A smart phone app selling for $5 would have been much more cost effective. Instead of using a phone that has already been paid for, now they have to pay for specialized hardware that costs $100 - more than some smart phones.

It’s in my category of things which are an interesting idea, but which should be a tablet app instead of a piece of hardware.

This is perhaps the most interesting graphing calculator to have come out since I started following the industry. The developer is French, and there hasn’t been very much discussion at all on English-language forums.

Features:

• Full Color This is a feature we’ve seen in almost all graphic calculators released after Casio led the way with the Prizm in 2011. It’s to be expected, and that’s a good thing.
• Modern Processor This is another base requirement for a modern calculator. z80s and m6800s were fine in the 80s and 90s, but we have much faster, cheap, and off-the-shelf hardware now.
• Open-Source Hardware and Software Probably the defining feature of the calculator, the platform’s open design is extremely refreshing after years of proprietary calculators from every major manufacturer.
• Free online simulator On other calculators this is an extra paid downloadable program. Making a naturally cross-platform emulator is exactly the right move. There is also a native version if you want to tinker with the OS.
• Integrated python interpreter With the HP Prime’s “python,” and the python interpreter on Casio’s fx-CG50, python is another emerging standard in calculators. I’ll take it any day over BASIC, but HP fans are probably sad to see RPL go.

Shortcomings:

• Lack of Mathematical Features There is a severe lack of functionality that comes standard with every other graphing or scientific calculator. There are no probability functions beyond the normal PDF and CDF (and a separate “app” with some basic distributions), no base or unit conversions, no finance/TVM functions, no advanced matrix operations.
• No app interoperability On every other graphing calculator, it is easy to use data from other modes, such as variables and results. Here, no data is shared at all, even between the regression and statistics apps.
• No symbolic math or CAS Not every calculator has this, but a CAS could easily be implemented on a calculator like this.
• Clunky Interface Using common functionality is easy enough, but for everything else one has to navigate through several menus using nothing but the arrow keys. There are no shortcuts of any kind (such as function keys, or skipping through menus with number or letter keys).

A lot of these issues are in software, and they’ve come a long way since their initial release (which didn’t even include log (!)). There is still quite a ways to go, but the open platform makes me excited about the future for this calculator.

down already?

switter.at seems to just be dating/mildly sexual ads?

What am I supposed to do with that json file? edit: … oh, it renders completely differently on desktop…

The most glaring omission on the post is Infer from Facebook. I woud rate Infer as the most impressive open source C/C++ static analyzer, by far.

I used a Samsung ARM Chromebook for about three years, Arch Linux ARM. It taught me that there are two facets to support:

1. Can other people help you with your device
2. Can you fix your own device

Generally #1 is lower when you use less popular platforms, and I was prepared for that. As someone who is used to fixing everything from hardware (scopes, solder and rosin inhalation) to software (they were sending ARPs how fast?) I was also prepared for #2.

Or so I thought.

Whatever you do: do NOT get a device that demands a signed bootloader. The bootloader on this device was forgetful, easily corrupted, rude (“You’re not running Chrome OS! Please press space twice so I can wipe everything!”) and most of all: not replaceable. Only Google had the keys, and I had to live with it.

Initially I had a second stage of u-boot installed that I had control over. This was brilliant. The Arch Linux ARM install instructions for this device used to have this as part of the recommended setup. That changed at a later point – a story that involves a post-install script for a newer kernel package dd’ing over my root partition.

I was stuck on a very old kernel version provided in the ALARM repos, I believe the one the original ChromeOS shipped with. This caused me many dramas, including making systemd flat out refuse to boot my device. “You don’t have cgroups support? Pah! I’m on strike. You didn’t need your computer to boot anyway, did you?”.

I have a couple of stories written up about my experiences:

• http://halestrom.net/darksleep/blog/006_chromebook/
• http://halestrom.net/darksleep/blog/005_distrohop_p1/

A quick summary of the fun side of things used to live in my /etc/issue:

Welcome to Clusterlizard, chamber \\l.  Please praise your selected deity(s)

Summary of interesting failure stories since December 2013:
 - 'debug' on kernel command line -> systemd becomes very verbose -> random race conditions due to text output -> crash
 - filesystem death on SSD by power-cycling too rapidly whilst debugging other issues
 - btrfs failure from trying to compile firefox ("ran out of inodes" even though btrfs does not use inodes)
 - systemd update -> required kernel support for xattrs on folders -> refused to boot
 - empty Chinese take-away containers + bag + laptop -> cracked the screen
 - systemd update -> prevented kernel from loading userspace wifi firmware
 - occasional bootloader corruption, fails to work until battled into a soft-reset after many attempts
 - upgraded many packages, write-cache filled memory, OOM -> system hung, filesystem left inconsistent 
 - updated kernel -> post-install script dd'd bootloader over my root filesystem 
 - updated kernel -> shorter wifi scan argument list support -> can't connect to wifi at uni, too many networks

Misc self-inflicted
 - removed systemd-sysvcompat
 - custom init system: spawned gettys with wrong arguments -> no logins
 - repeat episodes of systemd firmware issues

Happy birthday Clusterlizard! (2014 and 2015 and 2016)

Having many things go wrong with systemd whilst on a remote Greek village mountainside lead me to write my own init. But that’s another story.

What finally forced me to stop using the laptop was a failure of the inbuilt storage coupled with bugs in the evil bootloader. The onboard flash storage (MMC) became very slow over time (down to ~2MB/s write toward the end), but this wasn’t my major concern. What really hurt was when the the laptop started hardlocking when I did heavy disk I/O, such as updating.

Updating became a dangerous game. I’d try to workaround the problem by constantly interrupting the process and forcing disk sync, but this was tedious and slow. Worst of all: when the laptop locked up during updating I would find many of my system libraries left zero bytes long.

After about the third or fourth time that I had this happen I decided I needed some change.

Unfortunately this device had no internal connectors for replacement storage. The internal MMC was soldered directly onto the motherboard (BGA packages, not easily replaceable). But I thought I could use an SD card or USB stick instead.

USB and SD boot were how I originally installed (and repeatedly fixed) the ALARM installation. But now, out of the blue, the signed bootloader had decided that USB and SD card booting were verboten. “Hmm”, I thought, “perhaps those configuration bits had flipped?”. Not only that, but the configuration region had become write-locked. I have no clue why, the bootloader was still in the “developer” mode, and I tried many things to resolve it.

I found it hard to stop using my Arm laptop. I still occasionally get it out for the smell, it brings back many memories of many places. It has been the lightest and longest lasting laptop I have ever owned. It had many physical construction issues, was held together with hot glue, and the performance was non-existant in the graphics department. But it was different, it was something I could afford, and it was fun.

RIP clusterlizard, 2016

Epilogue: I now use an 11.6” refurbished DELL Latitude 3150. It suffers phantom stuck keys, screen backlight stability issues and I had to warranty the battery a month after buying it. It’s heavier, has a smaller keyboard (complete with a keyboard bezel!) and doesn’t smell anywhere as iconic as my ARM laptop did.

But when it breaks, I have many more options to fix it.

see also the previos discussion

Somehow, this reminds me of shoutboxes from back in the day.

Is there a graph showing how well it holds up?

Have there been any updates? This paper is 5 years old.

Is there any way to zoom out? The text is too large to read comfortably.

The vcs tag seems wrong. Git works fine without GitHub. This is more a business story.

rw does not support copying sparse files, a feature found on some operating systems.

Can’t you seek to the end of the input file and then truncate the output to that length?

rw is not yet able to determine the size of block devices on Illumos, Minix, NetBSD, and OpenBSD.

Same question here: does lseek(fd, 0, SEEK_END) not work?

Continuing tinkering on my filesystem driver. It’s looking more and more like I’m going to have to copy generic_file_read/write_iter and mpage_read/writepages wholesale and modify them to correctly deal with file data not being block-aligned. I’m not looking forward to this, as it means keeping track of changes to these functions upstream and porting them back over.

How does one do P2P on a web browser? Do you open WebRTC connections with other Peertube users?

This is becoming an increasingly severe problem in HPC. To the point where software needs to be written in an explicit fault-tolerant fashion, since errors like these or even hardware failures will happen on nearly every exaflop run. Even petaflop machines that are typical today need to have special handling for hardware failures to avoid crashing constantly.