I'd strongly suggest not to use find -L for the task (see below for explanation). Here are some other ways to do this:

If you want to use a "pure find" method, and assuming the GNU implementation of find, it should rather look like this:

find . -xtype l

(xtype is a test performed on a dereferenced link)

The data=writeback mount option deserves to be tried, in order to prevent journaling of the file system. This should be done only during the deletion time, there is a risk however if the server is being shutdown or rebooted during the delete operation.

According to this page,

Some applications show very significant speed improvement when it is used. For example, speed improvements can be seen (...) when applications create and delete large volumes of small files.

The option is set either in fstab or during the mount operation, replacing data=ordered with data=writeback. The file system containing the files to be deleted has to be remounted. //

He could also increase the time from the commit option: "This default value (or any low value) will hurt performance, but it's good for data-safety. Setting it to 0 will have the same effect as leaving it at the default (5 seconds). Setting it to very large values will improve performance". –
Cristian Ciupitu Commented Sep 26, 2010 at 19:14

Lastly, FYI, not mentioned in that link is that fact that data=writeback can be a huge security hole, since data pointed to by a given entry may not have the data that was written there by the app, meaning that a crash could result in the old, possibly-sensitive/private data being exposed. Not a concern here, since we're only turning it on temporarily, but I wanted to alert everyone to that caveat in case either you or others who run across that suggestion weren't aware. –
BMDan Commented Sep 27, 2010 at 1:23

cat is surely the best way to do this. Why use python when there is a program already written in C for this purpose? However, you might want to consider using xargs in case the command line length exceeds ARG_MAX and you need more than one cat. Using GNU tools, this is equivalent to what you already have:

find . -maxdepth 1 -type f -name 'input_file*' -print0 |
  sort -z |
  xargs -0 cat -- >>out

what is the fastest method to CREATE a thousands of files? Also, does it really matter if there is data in them, if they are just being deleted?

Using rsync is surprising fast and simple.

mkdir empty_dir
rsync -rd --delete empty_dir/    yourdirectory/

Crucial early evolutionary step found, imaged, and ... amazingly ... works

Computer History Museum software curator Al Kossow has successfully retrieved the contents of the over-half-a-century old tape found at the University of Utah last month.

UNIX V4, the first ever version of the UNIX operating system in which the kernel was written in the then-new C programming language, has been successfully recovered from a 1970s nine-track tape drive. You can download it from the Internet Archive, and run it in SimH. On Mastodon, "Flexion" posted a screenshot of it running under SGI IRIX.

https://archive.org/details/utah_unix_v4_raw //

The very first version of Unix, later known as the "Zeroth edition", was hand-coded in assembly language by Thompson in 1969. He wrote it for a spare PDP-7 at Bell Labs, a Digital Equipment Corporation minicomputer from 1965. The PDP-7 was an 18-bit machine: it handled memory in 18-bit words. This was so long ago that things like the eight-bit byte had not yet been standardized. PDP-7 UNIX was reconstructed from printouts between 2016 and 2019.

It did well enough that a few years later, Thompson got his hands on a PDP-11. Thompson rewrote his OS for this 16-bit machine – still in assembly language – to create UNIX First Edition. At first, the machine had a single RS11 hard disk, for a grand total of half a megabyte of storage, although the rebuilt source code is from a later machine with a second hard disk.

All the mainstream distros (Ubuntu and Mint, openSUSE and Gecko Linux, Fedora, Debian) come with largely the same choice of desktops, and they're all the same. //

I am also not saying that any of these environments are bad. I have my own preferences, but I completely respect that other people have their own. That's fine too.

That is not the purpose of this piece.

What it is asking is: why are they all the same?

So many different implementations of the "traditional" (since 1995) taskbar-and-launch-menu are not different desktops.

Yes, there are differences, but they are trivial and cosmetic. //

The hidden price of duplicated effort
A very important aspect of this is accessibility. Not only for blind users, but they make a good example. GNOME 2 was reasonably good for people without eyesight, but it's gone, and none of its inheritors come close to matching it.

An excellent and very simple test of accessibility is to use a desktop PC and just unplug the mouse. Windows remains highly usable with only a keyboard. As standard, without enabling any special accessibility aids, windows can be opened, moved, resized, switched and closed, entirely with the keyboard. //

The accessibility features and keyboard controls of macOS are not available at all until enabled, whereas in Windows, they are part of the standard UI, there for everyone to use. //

There are other designs out there. There are more desktops than Windows and macOS, and all offer their own unique benefits. Reimplementing the same old desktop model over and over again doesn't help anyone: it just wastes a huge amount of talent and effort. ® //

Tuesday 17th May 2022 08:55 GMT
DrXymSilver badge
The curse of overchoice
Overchoice is actually a term for when a consumer is given so many options, often varying in ways which are meaningless or confusing that they end up making no choice at all.

Linux has always had that issue and it is illustrated in the article in all the desktops that exist or existed. I expect most prospective Linux users just want to install the thing and use it for something. They really don't care what desktop is powering their experience providing it is easy to use, discoverable, familiar, doesn't throw any nasty surprises at them and lets them get on and do stuff.

There are an almost ridiculous number of Windows-style desktops on Linux – and mostly this applies to the BSDs, too. Most of them are implemented in C, and most use various versions of the Gtk toolkit for their widgets: menus, dialog boxes, buttons and so on.

In approximate age order, the ones still being maintained today are Xfce; MATE, which is a fork of GNOME 2; LXDE; Linux Mint's Cinnamon; and Budgie, implemented in the GNOME-centric Vala language. //

Now we're up to 23. We could dig deeper, but we hope that we've made the point by now. There are several different languages here (but a lot fewer than 23 of them), and several different graphical toolkits (but again, well under 20). This is a vast amount of effort spent reinventing, and then maintaining, the basic concept of a round thing on the end of an axle.

But the underlying concept here is really quite a simple one. The window managers can't match the functionality of the Windows 95 Explorer, and not one of the desktops captures the simple elegance of the original. Windows 95 let you put the taskbar on any screen edge, but you only got one, and you couldn't change its length, or re-arrange or resize its contents, let alone change their orientation. Multiple rows was your only option. //

Remember the Basics of the Unix Philosophy:

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

That 1995 design was simple. The components of the desktop – the task bar, the file manager, the text editor, and so on – don't need to exchange lots of rich, complex messages. //

Nearly two dozen different Windows-like UIs represents a titanic waste of programmer effort, skill, and time. Hundreds, maybe thousands of people, working hard for decades… but all on different projects, meaning that none of them achieve greatness. For an example, look at KDE Plasma's 36 launcher menus.

It is 27 years since the first release of KDE, and I suspect that Microsoft has been laughing all the way to the bank ever since. The FOSS world can do better, and it's time it started to try. ®

It might have the first-ever version of UNIX written in C

A tape-based piece of unique Unix history may have been lying quietly in storage at the University of Utah for 50+ years. The question is whether researchers will be able to take this piece of middle-aged media and rewind it back to the 1970s to get the data off.

sed is a stream editor. A stream editor is used to perform basic text transformations on an input stream (a file or input from a pipeline). While in some ways similar to an editor which permits scripted edits (such as ed), sed works by making only one pass over the input(s), and is consequently more efficient. But it is sed’s ability to filter text in a pipeline which particularly distinguishes it from other types of editors.

Alan J. Wylie

VMS got it right

VMS (since 1977) has stored time as 100ns clock ticks since 17 November 1858 (the start of the Reduced Julian Day (an astronomical timescale, the "reduced" variant was introduced by the Smithsonian Astrophysical Observatory in 1957 to record the orbit of Sputnik). It will run out of bits in the year 31,086.

Evil Auditor

Re: VMS got it right
...and about 29,000 years from now, someone will have discovered an ancient calculation machine and will have figured out how it worked. And they will see that its clock stops in the year 31,086. And some of them will start a cult that believes the end is near for an ancient civilisation allowed their calender to run until then...

Phil O'SophicalSilver badge

Re: VMS got it right

VMS got most things right.

There is, though, a well-known bug filed against VMS for a related issue. The standard message display only permits 4-digit years, so even if the clock is fine until 31,086 there will be a display error when it ticks over on Dec 31st 9999. Last time I saw that bug in the DEC tracking system it was in an 'accepted' state, with a note that it will be fixed "in a future major architecture". Sadly unlikely now...

Feeling old yet? Let the Reg ruin your day for you. We are now substantially closer to the 2038 problem (5,849 days) than it has been since the Year 2000 problem (yep, 8,049 days since Y2K).

Why do we mention it? Well, thanks to keen-eyed Reg reader Calum Morrison, we've spotted a bit of the former, and a hint of what lies beneath the Beeb's digital presence, when he sent in a snapshot that implies Old Auntie might be using a 32-bit Linux in iPlayer, and something with a kernel older than Linux 5.10, too.

That 2020 kernel release was the first able to serve as a base for a 32-bit system designed to run beyond 03:14:07 UTC on 19 January 2038. //

Like Y2K, it's easy to explain and fairly easy to fix: traditionally, UNIX stored the time as the number of seconds since January 1, 1970 ­– but they held it in a signed 32-bit value. That means that at seven seconds after pi o'clock in the morning of January 18th, 2038 (UTC), when it will be 2,147,483,647 (2³¹) seconds after the "epoch", the next time will be -2³¹: 20:45:52 in the evening of December 13th, 1901.

It has already been fixed in Linux and any other recent UNIX-ish OSes. The easy way is to move to a 64-bit value, giving a range of 292 billion years either way. That'll do, pig.

The fun bit is finding all the places it might occur, like this fun (and old and long-fixed) MongoDB bug. MongoDB stores the date correctly, Python stores the date correctly, but dates were passed from one to the other using a 32-bit value.

vtcodger

Re: Attitude problem
YOU may have spent New Years Eve 2000 at a great party. I and many others I'm sure, spent New Years morning,2000 booting 100-plus PCs to make sure they at least sort of worked -- never a certainty with Windows-98 even on normal mornings.

MiguelC

Re: Attitude problem
I was on duty that evening. At midnight we nodded, saluted each other, and went to work checking everything was running smoothly. Having had no alerts whatsoever, at around 1AM I went to the nearest ATM and checked my balance and latest account movements (an account in another bank than the one I was working for at the time). There was an interest credit of around the equivalent of 3000€. Resisting the urge to spend it there and then, I went back, showed the slip to my co-workers and pondered on what would happen from there on. At 8 AM, after an uneventful night on the job, I went down and checked my balance again. Without a trace of that earlier payment, it now showed the correct and, unfortunately, much smaller interest deposit...

Someone's night was indeed a lot more eventful than mine ;) //

Bill GraySilver badge
Reply Icon
Re: The bug is in the support library code (libc?) of a 1982 C compiler?

I suspect most time library code of this vintage also omits the year 2000 leap year (as I recall SGI Indigo Irix 4 did) and would be a day out after 2000.02.28.

I dunno how common that particular error would be? To screw things up that way, you have to simultaneously know that (in the Gregorian calendar) "century" years are not leap years, but also not know that years evenly divisible by 400 are leap years. That is to say, you have to be a little ignorant, but not completely ignorant.

If you're completely ignorant of the problem, you'll say that 2000 should have a leap day, and be correct for the wrong reasons.

Museum boffins find code that crashes in 2037

A stark warning about the upcoming Epochalypse, also known as the "Year 2038 problem," has come from the past, as National Museum Of Computing system restorers have discovered an unsetting issue while working on ancient systems.

Robin Downs, a volunteer who was recently involved in an exhibition of Digital Equipment Corporation (DEC) gear at the museum, was on hand to demonstrate the problem to The Register in the museum's Large Systems Gallery, which now houses a running PDP-11/73. //

"So we found bugs that exist, pre-2038, in writing this that we didn't know about."

The Year 2038 problem occurs in systems that store Unix time – the number of seconds since the Unix epoch (00:00:00 UTC on January 1, 1970) in a signed 32-bit integer (64-bit is one modern approach, but legacy systems have a habit of lingering).

At 03:14:07 UTC on January 19, 2038, the second counter will overflow. In theory, this will result in a time and date being returned before the epoch – 20:45:52 UTC on December 13, 1901, but that didn't happen for Downs. //

zb42
As the article is specifically about date problems that occur before the 32bit unix time rollover, I think it should be mentioned that:

32bit NTP is going to roll over on the 7th of February 2036.

Here is another reverse lookups done using dig command:

$ dig -x ip-address-here
$ dig -x 75.126.153.206

FreeBSD uses try the drill command:

 drill -Qx 54.184.50.208

Sometimes you only want to modify files containing specific content. Combine find, grep, and sed:

# Only replace in files that contain the old text
find . -name "*.yaml" -type f -exec grep -l "oldValue" {} \; | xargs sed -i 's/oldValue/newValue/g'

awk is used to filter and manipulate output from other programs and functions. awk works on programs that contain rules comprised of patterns and actions. The action awk takes is executed on the text that matches the pattern. Patterns are enclosed in curly braces ({}). Together, a pattern and an action form a rule. The entire awk program is enclosed in single quotes (').

The sed command is a bit like chess: it takes an hour to learn the basics and a lifetime to master them (or, at least a lot of practice). We'll show you a selection of opening gambits in each of the main categories of sed functionality.

sed is a stream editor that works on piped input or files of text. It doesn't have an interactive text editor interface, however. Rather, you provide instructions for it to follow as it works through the text. This all works in Bash and other command-line shells.

his text is a brief description of the features that are present in the Bash shell (version 5.2, 19 September 2022). The Bash home page is http://www.gnu.org/software/bash/.

This is Edition 5.2, last updated 19 September 2022, of The GNU Bash Reference Manual, for Bash, Version 5.2.

Bash contains features that appear in other popular shells, and some features that only appear in Bash. Some of the shells that Bash has borrowed concepts from are the Bourne Shell (sh), the Korn Shell (ksh), and the C-shell (csh and its successor, tcsh). The following menu breaks the features up into categories, noting which features were inspired by other shells and which are specific to Bash.

This manual is meant as a brief introduction to features found in Bash. The Bash manual page should be used as the definitive reference on shell behavior.

NetBSD/i386 is the port of NetBSD to generic machines ("PC clones") with 32-bit x86-family processors. It runs on PCI-Express, PCI, and CardBus systems, as well as older hardware with PCMCIA, VL-bus, EISA, MCA, and ISA (AT-bus) interfaces, with x87 math coprocessors.

Any i486 or better CPU should work - genuine Intel or a compatible such as Cyrix, AMD, or NexGen.

NetBSD/i386 was the original port of NetBSD, and was initially released as NetBSD 0.8 in 1993.