kbr2000

I'm using Fossil for this: https://fossil-scm.org/ Written by the SQLite author (and based on SQLite).

By reading 'The art of computer programming' (Knuth) from cover to cover :) He'd be more than willing to listen to you then (according to his own words, ironically printed on the backcover of my copy of TAOCP).

Tnx, that's nice. I like your 1 condition!

It would be good practice to do so, when you are referring to a FQDN.

Apart from that, to circumvent badly configured paywall filters?

I might have some time this summer, feel free to contact and explain ;)

You can use proc command in Tcl to replace existing commands and procedures, which gives you the possibility to implement different behaviour.

An example that shows this:

  ~$ tclsh
  % rename while origwhile
  % proc while {args} {
      puts stderr "Debug: invoked while with arguments $args"
      # do anything you want here
      uplevel 1 origwhile $args
    }
  % set i 0
  % while {$i < 5} {puts $i; incr i}
  Debug: invoked while with arguments {$i < 5} {puts $i; incr i}
  0
  1
  2
  3
  4
  % 

And in Forth the dictionary is searched backwards for a word (starting with the most recent definitions), so you can similarly override words. Powerful!

rsync went quite fine while transferring data (in the same situation as you describe), when taken care of some important bottlenecks (not running it over SSH, disabling compression on files that don't compress well, disabling full checksums, TCP sockopts, ...)

what it might leave you hanging with for a long time is before an actual transfer, while it builds and compares the lists on both sending and receiving side, when you have big filesystems (hundreds of millions of files).

if you have a strategy to select beforehand which files to transfer (for example from a DB which tracks what has been created or changed, direct from worker or production input) you have a good headstart and can minimize rsync on complete filesystems -- and rather run it on a selection, which is tiny compared to the complete project(s) most of the time.

Tnx, that one I didn't know...

You can drop another command as such:

   lsof |awk '($10 ~ /^\/home\//) {print $10}' |sort -u

It's likely the only way to stay sane in a corporate environment. The problem is, you don't need much people practicing that, before it drags everyone down to the same niveau. You can choose to try to continue your quest into doing work seriously (this will likely drive you insane over the years), or to join in that kind of negligence (goodbye spine), or to quit. In the end it got us where we are now, a world filled with fake companies selling their fake little products as they were qualitative, and making a game of disrespecting their own customers. Pure facade, been there...

I've done it before, but I'll recommend to you Scott Adams' book, The Dilbert Principle for some light reading about forces like that at work.

DRAAA := didn't read at all (again)

It got a lot worse since 'devops' came around, in my experience. As an example: people started getting increasingly pissed off when proprietary software (unpackaged, but usually with a shell installation script) couldn't get installed on a network wide setup of ~200 nodes fast enough to their liking. Since at home they could do that in 15m following the vendor's instructions (which involved running the installer script as root).

It fell to deaf ears that a packaged approach was the right way to go, given said software installed its own jungle all around the filesystem hierarchy, numerous times conflicting with software from other vendors with the same kind of recklessness.

Quite clear that any of these people lacked the understanding that having a longterm stable environment where everyone uses the same version of everything, is uncomparable with doing unsafe installations following the first forum-post you find online.

Devops learned them that cutting corners to empower yourself is OK, they could run their own systems quicker. Needless to say all the debugging (the search-engine based kind) that needed to be done after the facts was suddenly part of their job description, and filled up most of their time...

Indeed, which is what they're doing here: the OP only posts RedHat fabrications like that in here...

They don't see that as part of their job. On the short term that behaviour probably doesn't create problems for them. On the long term, they likely will be responding to job adverts themselves :)

Anyway, no answer is sometimes preferable to some of the nonsensical standard doublespeak letters you might receive ("niet weerhouden...").

Respect is far to be found in these HR practices, in my experience. It usually reflects in the business who took them on board. Once you see through all these efforts to make people behave exactly like they want, I doubt there will be much workplaces left considering.

Well, thank you a lot Randy! Great idea, good times...

In case this interests someone, I recommend you to check out Jason Scott's BBS Documentary [http://www.bbsdocumentary.com/], and while the DVDs sold out, it seems to be available on his youtube channel [https://www.youtube.com/watch?v=Dddbe9OuJLU&list=PL7nj3G6Jpv...].

PS. adding a trailing dot after .com in the article URL saves you some trouble :)

A management fad called dev-ops is what went wrong, before you could count on your sysadmin to take care of that :) Apart from that, not everything always makes sense to use in production without a good level of understanding --- and might otherwise lead to, for example, a false sense of security.

Yes, and even two or three, not to put all your eggs in the same basket...

Managers and C-levels surely have appetite for this. In the end it just degrades mostly to trial-and-error, which I'm sure is no problem because the people have to do the real work get sick of it and get replaced (sometimes voluntarily, sometimes with force), or play the game nice out of fear losing their job (thus feeding the beast).

It's not very surprising since 'products' nowadays are more like 'services' instead, and offer some kind of encapsulation: people are not interested much in how something ticks behind the scenes, and so it can drive down the behind-the-scene quality. They also are conditioned to accept lousy excuses (including none) for outages and breakdowns, because they got sold 'magic', and boy that is magical..

You'll might have to work in obscurity to keep up operations quality, which is in turn a driver for your own demise. Game over.

I'd like to suggest to you the following reading material:

- Bullshit Jobs (David Graeber, 2018)

- The Dilbert Principle (Scott Adams, 2000)

- Future Shock (Alvin Toffler, 1970)

Correct. Also, they won't give you that money if they know your motivation is the will to fix things. The money flows instead to the ones who have receiving more money as their motivation.

I experienced this several times as an employee. It becomes hard to stand when you realize that every positive contribution just results in more money being shoveled out of the window behind your back (mainly because of greed, inefficiency, keeping the status quo, and wreckless behaviour caused by trust in your capabilities to somehow fix it again, every time over again) -- as opposed to contributing to a more efficient way of working for everyone.

Been doing extreme over-hours in the hope of fixing stuff once and for ever, only to realize your job becomes more and more like shit-shoveling, since management starts to feel invincible (and protected by your contributions), which leads them to make even more errors without accountability. I've seen some of them with tears in their eyes when I finally quit. 'nuff said. Profiteurs!

Because... they dance the devops dance with their devop hats on! Security problems can be swiftly danced around until they actually surface, and can then be handled in the next round of "continuous delivery". It's also smart to postpone solving most issues until after they occur, so sales can continue bragging about "continuous improvement".

Debatable, but it might

+ save some network bandwidth in case of a sufficiently large/complex document

- burn some extra energy client-side in case of a sufficiently large/complex document

+ allow some kind of interactive manipulation/modification by the reader

This reminds me of Bob Widlar (linear IC pioneer) and his "hassler" device [http://www.deceptology.com/2012-03/engineer-invents-device-t...]. Enjoy!

> Nuclear energy has the lowest death rate [...] Unfortunately, facts do not change our minds.

arguably, it's not the right technology to solve these human problems then. for that you'll need one with the highest death rate possible.

As Awk is a pattern-matching language, you can simplify it to something like this:

  ps aux |awk '/what/ {print "kill " $2}'

This will give you a list of kill commands you can review, before piping to |sh to shake off those processes :)

And when what you try to do sequentially might take too long, you can consider throwing GNU Parallel [1] in the pipemix!

[1] https://en.wikipedia.org/wiki/GNU_parallel

How does that work in practice? In order to page, you should find out if it is the code, and it is indeed broken. I'm guessing all tests passed, so that won't be of much help anymore neither...

In reality, it would be a sysadmin confirming dependencies for this application to run (in the system, network, storage, ...) are functioning as required. If there turns out to be a problem with the application itself, there's no time for development at that point: you roll back. I don't see how the paging developers thing would be able to provide any stability. It's too late for that when you're in production.

In order to move to your destination, after vertical take-off you would then need to fall down a bit first in order to pick up speed before transitioning to gliding (to get wind over your wings, which provides lift to turn and fly in the right direction).

You might want to ditch those empty batteries also at the right point :)

It's soon time to invent nano- and pico-services, so everything gets to be scalable by default. That way we can finally stop bothering about first examining the problem domain at hand, and pull out all the stops at once -- looking busy like bees in the process.

Excuse me while I construct this house from micro-bricks and molecular mortar first.

It seems more likely to me that those "devops tools" only solve a small slice of the big sysadmin cheese, and not in a flexible way (one useful skill of sysadmins is being able to react on the spot to what's coming to them at that moment, using basic tools and logical reasoning, much like a firefighter).

Being able to differentiate between what's worth to automate and what is not is another one of those useful skills. Knowing a scripting language to glue those basic tools together is too. Being proactive (assisted by monitoring software and knowledge of the underlying systems so you can tell what consequences some event have) is another...

None of that is new nor surprising to sysadmins. It might sound fresh to others, being trapped to reinvent a small slice of it (badly). Also, "devops" is just another funky management fad by now.

I remember it included both a floppy disk and a diskette, so you could choose a suitable one for your system to boot from, and continue with the CDROM. (a 1x speed Mitsumi drive with manual sled loading[0] at the time)

Booting directly from CDROM media wasn't even available until mid-90ies if I recall correctly.

[0] https://www.youtube.com/watch?v=CUBeHWVHh9U