Sqlite in WAL mode will never lose all your data and performance can be configured vs durability by setting pragma synchronous to full or normal.

In other words, I want to disable all jobs for some time (for benchmarking) and then bring them back up.

  > The DC-ROMA RISC-V Pad II starts at $149 for the 4GB RAM version and is already available for pre-order on the DeepComputing store. 
  > If you get the 16GB RAM variant, the tab is compatible with the Android Open-Source Project (AOSP) Android 15 operating system.

I'm looking to buy a (new) 10'' tablet for that purpose.

How do you tweak these? I'm aware of dirty_writeback_centisecs and the likes, but you are most likely referring to something different.

No need to be imprecise, unless you are trying to push some agenda. The cost is CHF 198, which is around USD 195.

It would be interesting to measure git vs JGit performance today.

It would also be interesting to have JGit developers comment on performance after all this time.

  * 5.25'' drive  which is taller (more platters) and wider (more sectors per platter)
  * Slow rotational speed to reduce consumption and vibration
  * SMR again, but label the products accordingly
  * Small (64-128GB) SSD embedded, acting as transparent cache especially for quick response to write commands.
    * Possibility to disable this caching layer with a SATA command.

Systemd requiring polkit is a valid issue.

  - You bubble up errors using `?` operator,
  - then you get a nice error message.
  - However the location of the error is lost, the more complex the program, the harder it is to figure out where "permission denied" for example comes from.

  I had implemented it once in 2 lines of Python. some 25 years ago. If I can shake the rust maybe I'll be able to rederive it. 

Has it been running on a single node all these times? What are the hardware specs? How many requests per second did it handle? Has it gone down because of the load? What was the bottleneck (network, cpu io)? How did it fail (crash, slowness, fire ;-)? Do you have monitoring data to show? How many twitter-like active users would it be able to serve from that single node?

Thanks, and Blërg! :-)

  But what's wrong with Twitter?

  I'M GLAD YOU ASKED. There are two aspects of Twitter that just bug me as an engineer:

    Ruby on Rails - Using rails to prototype a system is fine — scaling up to a million hits a day with it is just a bad idea. As the service grew, I'm sure it cost them a lot more time than it saved.
    140 characters is not enough - I routinely write sentences longer than 140 characters, so I can't even begin to imagine making a point in such a small space. This textual confinement has led to the rise of URL shorteners, which are breaking the internet. 

  Blërg solves these problems by applying absurd reactionary engineering. Blërg's database backend is a custom C program that handles requests over HTTP and stores data in a very small and efficient indexed log-structured database. The frontend is done entirely in client-side Javascript. A single post can be up to 65535 bytes in length.

  Which is not to say that I believe writing your service in C is the solution to all your problems. Clearly, this approach has just as many hairy problems that will bite you in the ass sooner or later. The best way, as with most things, lies somewhere in the middle of high-level abstraction and ZOMGHARDCORE OPTIMIZATION.

   Blërg is a minimalistic tagged text document database engine that also pretends to be a microblogging system. It is designed to efficiently store small (< 64K) pieces of text in a way that they can be quickly retrieved by record number or by querying for tags embedded in the text. Its native interface is HTTP — Blërg comes as either a standalone HTTP server, or a CGI. Blërg is written in pure C.

Comments URL: https://news.ycombinator.com/item?id=25725778

Points: 122

# Comments: 67