Live data from Hacker News

Simple Systems Have Less Downtime

gkogan.co

251–260 of 271 posts

Re: Simple Systems Have Less Downtime

#251
post #231

Earlier quoted context omitted.

sorry for offtopic. there a broken link that I was interested to read on. its on https://www.rsync.net/resources/howto/rsync.html ctrl+f "rsync snapshots are detailed here" I think given the topic, someone is expected to figure it out on their own (remember linux cake?), but I feel a bit lazy after a work day.. sorry

Sorry - that is in purpose ... The definitive page for rsync snapshots has been, and always will be, here: http://www.mikerubel.org/computers/rsync_snapshots/ ... we actually don't want people to do rsync snapshots anymore because ZFS snapshots are much more efficient and use up less of their rsync.net account. If you change one bit of a file, the rsync snapshot method will cost the entire size of that file, since it…

Thanks for the link and explanations, appreciate it!

I've read that page (i linked) inattentively, re-read 3 times that bold text next to the broken link and still asked that question... :facepalm:

Re: Simple Systems Have Less Downtime

#252
Everything seems logical and simple. But the examples lack details and realism. Take for example this quote:

> In the end, the system I put in place had 97% fewer processes (from 629 to 20) while providing all the same capabilities. A bug that was found a few days later got resolved in four minutes.

It‘s called refactoring. It‘s a constant process, that none likes to allocate time to, because it does not move metric immediately. Especially in marketing with a very fast changing landscape you go from 20 to 600+ very fast.

Re: Simple Systems Have Less Downtime

#253
post #3

>For example, an analytics dashboard built with a no-code analytics tool like Looker is likely to have more qualified people to fix it than one built with a patchwork of custom scripts and APIs. Nobody should have to pull data scientists or product developers away from their work to fix a bar chart. I don't have experience with Looker, but the unseen complexity of no-code tools often leads to very complex systems wit…

Spot on. Looker is a great tool, but it has its own language LookerMl and a set of abstractions. From my limited experience it‘s not easy to pick up. It‘s likely that an analyst is already familiar with it. But like with any BI if there is a problem that can‘t be solved with an existing abstractions and tools, you either go back to writing the pipeline step to solve or you come with a very ugly solution.

Re: Simple Systems Have Less Downtime

#254

I like the ship analogy from the article. The fact it is so robust is not because the system as a whole is simple, but because its components have well defined, narrow responsibilities and there are abstract interfaces between them, which hide a lot of complexity. You don't need to understand the internals of the pump to explain what it does, even though the actual internal technology may be quite complex and clever.…

A startup is not a container ship going between port A and port B where everything is known. A startup is a new destroyer that has been floated, did not have sea trials and went to war with a crew that might have a couple of people that used to a drive container ship but mostly staffed with kids that thought it was cool to play with a destroyer. Oh, and 3/4 of the systems are still at best have been drawn on a napkin…

I would say a startup is a ship that has been floated. But it‘s unclear if it needs to be a destroyer or a cargo ship, or a cruise ship. Later on it may turn out to be a spaceship.

Re: Simple Systems Have Less Downtime

#255
post #150
post #117

Earlier quoted context omitted.

Warehouse/Workshop Model is more simple, the large industrial assembly line is the mainstream production technology in the world. But simplicity does not mean easy. It is actually systematic engineering. It is difficult to design a complex system into a simple and smooth Warehouse(database, pool)/Workshop(pipeline) Model system. https://github.com/linpengcheng/PurefunctionPipelineDataflow

Is there any way I could convince you to stop clogging up the internet pipes with comments that seem to solely focus on 'pipes' and 'warehouses'? Surely there are other things that you care about and could contribute to HN? At this point it's literally spam. EDIT: Literally figuratively speaking, of course.

In fact, when you comment, my github adds 5 stars, this shows that my information is valuable. and I have all posted comments on related topics.

I think you should enhance your ability to appreciate technology, Too poor technology should learn more, instead of criticizing others.

Re: Simple Systems Have Less Downtime

#256

Earlier quoted context omitted.

That problem is not limited to Lisp. As a programming language, Common Lisp is large enough and multi-paradigm enough to allow for elegant solutions to problems. It does require some experience with the language and some wisdom and discipline to know what pieces to select and how to best use them. However, like all large, multi-paradigm programming languages that have been around for a while (I'm looking at you C++),…

> programmers tend to carve out their own subsets of the language which are not always as well understood by those who come after them if the language is not powerful enough to allow for that people will inevitably add preprocessors, code generators, etc... to do the things they want.

>> if the language is not powerful enough people will inevitably add preprocessors, code generators, etc... to do the things they want.

This is definitely true and it adds to the accidental complexity of the system, usually to save programmer time or implement layers of abstraction for convenience.

Common Lisp and C++ have both incorporated preprocessors and code generators through Common Lisp macros and C++ template metaprogramming and C++ preprocessor / macros. These features give the programmer metaprogramming powers, enable domain-specific language creation, implement sophisticated generics, etc.

They are powerful language facilities that need to be used wisely and judiciously or they can add exponential complexity and make the system much more difficult to understand, troubleshoot, and maintain.

Re: Simple Systems Have Less Downtime

#257

Earlier quoted context omitted.

> I've maybe had to do that 5 times in the last...10 years? Good for you. Some of us have to install up to date software more often than every 5 or 10 years.

I'm running Arch on my office workstation. I install up to date software literally every day.

Only after a third party makes an AUR for it. I'll stick to an OS where the developer can publish directly to the users without 15 different packaging formats, thanks.

Re: Simple Systems Have Less Downtime

#258

Earlier quoted context omitted.

Bullshit. You're talking about an operating system where the common advice for someone who wants to install up to date software is to fucking compile it from source because the whole community never got their collective shit together enough to allow developers to directly distribute binaries without a gigantic fucking headache. Christ, it's such a fucking mess that one of the most compatible ways to distribute softwa…

> compile it from source Way simpler to do on Linux than M$ Windows. > [no way to ] to directly distribute binaries without a gigantic fucking headache. I mean, flatpak, appimage, docker, etc ...

> Way simpler to do on Linux than M$ Windows.

Completely unnecessary on Windows since it is an operating system, not a kludge of random source code from the internet.

> I mean, flatpak, appimage, docker, etc ...

Which of those is ubiquitous enough to ensure availability of what you're looking for in that format? In my experience: none of them. AppImage is easily the best, but the community seems to hate it because it makes things too flexible and simple or something.

Re: Simple Systems Have Less Downtime

#260
post #143

I gave a talk on this subject at CU last year and have, one way or another, spent my entire professional life thinking about this topic. I agree wholeheartedly that simple systems have less downtime. I would like to add a line from the talk that I give: Simple systems fail in boring ways. Complex systems fail in fascinating, unexpected ways. rsync.net storage arrays typically have multi-hundred day uptimes. But acros…

"simple systems have less downtime" That is not much of an insight. It is as insightful as saying "water is kinda wet.". Well... sure it is. What we need to deal with, is not "make a simplest system". Rather, we need to deal with: "build a system that does A, B, C, ... and so on". Now, if you can do all of the above and make it simple... awesome. But if you cannot do all of the above, but the system is simple.... tha…

beware: for most is not that obvious. For most developers modern, extensible, layered comes before simple.
Post reply on HN