Figures in LaTeX documents (what to use?)

Shrimps do like driving powerful cars.

In the same state as yours. I'm perfectly happy with my 15-years-old internal combustion engine car, and don't feel any need to trade up. I'm not happy about the CO2 emission it's responsible for, but I don't use it all that often, and some of the electricity I buy is still being generated by burning coal.

If you have a better, and more economic and functional idea, then let's hear about it.

Modern os's have been developed and refined over decades, and for most applications, perfectly adequate to get the job done. However, all designed systems have limitations. Work within those limits and most of the time, they will work right every day in the week. Perfection not possible, but "good enough" strikes the right balance, and is sound engineering practice.

I think most os problems now are security related, where the basic system is stable. Haven't seen any serious os problems in years now, but maybe not too demanding here.

Ah, but there is the rub! "Economic" and "functional" are multivalued sets of constraints. How much "cost" do you associate with development effort? Correctness? Maintainability? Bugginess? etc.

If your sole focus is on "execution speed" -- and you delude yourself into thinking that is a measure of "performance" -- then you'll likely underweight and/or *dismiss* the effects of bugs, maintenance costs, need for frequent "updates", etc.

"But its fast!"

Think of how much can be saved by ridding automobiles of things like seatbelts, entertainment systems, emission controls, crumple bumpers, etc. Yet, we don't see many vehicles offered without those things -- because people place value on them above fuel economy, price, maintenance, etc.

There are a few things that experience designing systems (instead of just writing code or designing hardware) teach:

- you can always buy "performance"

- there are limits to what a single brain can grasp

- more brains leads to more misunderstandings

- memories fade/fail

The consequences of these are pretty obvious:

- next year's code will run twice as fast with no effort on your part

- next year's hardware will cost half as much (see above)

- if you can't grasp the entire system design, you've little hope for success

- if you can't CLEARLY express what you've done, you'll never recreate mindset

From this, it should be obvious that 15 million lines of code is laughable. If YOU designed a product that required that much support, your boss would walk you out the door in a heartbeat!

Removing a breast is a perfectly adequate solution to breast cancer. Why waste time exploring other alternatives?

Tell that to the woman getting fitted for her prosthetic ("Hey, you're ALIVE! Be thankful!!" <rolls eyes>)

I'm sure Windows users are thrilled with the regular updates they are coerced into receiving -- and the attendant changes in the UX that they are forced to accept.

And UNIX sysadmins must be delighted at the number of patches the AIs are uncovering -- for THEM to patch!

Security has several faces. The obvious one is protecting against malevolent actors. You (as a user) can do some things to minimize that: don't provide access to your systems, in person or via transport INTO (even sneakernet). For a "mature" OS, one has to wonder why there are still so many bugs being found -- especially for FOSS offerings that SUPPOSEDLY have the benefit of "lots of eyes looking at the codebase"!

But, security also reflects the integrity of the programming environment. Can a developer do something that (accidentally) makes a system less secure? (neglecting the fact that FOSS projects now seem to be targeted by malevolent actors slipping malware INTO those codebases where they can infect anyone who embraces those components!)

We have known (forever) that information hiding is a win for improving the quality and reliability of software. Encapsulating data and implementation BEHIND interfaces protects those data and implementations from abuse and corruption. So, why these HUGE kernels?? Does the keyboard handler REALLY need to be able to access the internals of the process scheduler? Or, the state of other processes that aren't currently EXECUTING?

Ah, but tearing down the barriers allows for higher "performance!" Isn't it great that we can share mbufs between the disk system and the protocol stack?! (YES! memory is so scarce in a PDP11!)

And, more unexpected bugs.

And, can a *user* do anything that "accidentally" compromises a system?

The whole security model is an afterthought. E.g., the notion of a superuser that assigns privilege to a particular "account" instead of a particular activity.

Anyone developing a device driver has to be "trusted", implicitly, as their code will be operating *in* the kernel with full access to all of the internals thereof. As if a superuser without any conscience! They, of course, never have bugs in their code, never have errant pointers that stomp on other parts of the kernel (residing in the same process container). It's somebody *else* who makes these mistakes...

A naive user can't stack up processes carelessly, can he? E.g., main() { while(1){ fork(); } }

Or, for those systems without a compiler: #!/bin/sh $0 & exec $0

Of course, the per-user process limit should fix this - at least limit the amount of damage that can be done. And, hopefully it isn't session-based as a frustrated user may simply login from another pty and repeat the mistake -- because he likely can't kill(8) his errant process!

Or: find / -name "*" -exec grep MyName {} \; of course, it won't let me look in any place that the file permissions (a bolt-on solution to an unnecessarily public namespace) prohibit. But, it will sure guarantee that the disk buffers are continuously being flushed (what was that issue about performance??)

Gee, is resource accounting even enabled? Note to self...

Etc.

Security is an afterthought in most OSs. It should be the *first* criteria as it NEEDS to permeate EVERY aspect of the design. If you rationalize it NOT being needed at a particular point in the design structure (usually because you see it as an unnecessary overhead -- drag on performance), you've created a focus for someone who seeks to compromise that system: "If I can get at ________ then I can..."

This is why you see embedded URLs in web pages that are obviously exceedingly long just to tickle a buffer overflow in a browser. Or, "startup macros" (rc's) exploited in shells, MSWord/Excel, etc. Or, filenames like ".malware " (will you notice the trailing space on your console listing?)

These are worth studying as they introduce different models for the role of the OS. Different ways that they address the perceived needs of the programmer. Each tries to focus on some aspect(s) that they consider important and a solution(s) that they hope will maximize the utility of that aspect.

But, often focus too much on that aspect and let other aspects suffer (or simply wither).

I design embedded systems, not desktop apps (though many observations still apply), so there's no one hovering over the system to catch it if it misbehaves, reboot, etc. And, the consequences of a f*ckup can be substantial (in terms of health/safety and financial loss). My current project is expected to run 24/7/365 for *decades* (no "downtime" to replace hardware, upgrade software, etc.)

When examining OS options, I realized:

- the filesystem is excess overhead. "Everything is a file -- except, of course, those things that aren't! We'll address THOSE issues with a variety of ioctl(2)s -- and conveniently ignore the fact that this EMPHASIZES the fact that everything is NOT a file" Rather, the file system is a SHARED GLOBAL NAMESPACE; everything is *referenced* as an entry therein (neglecting anonymous files) -- but, that doesn't make them all "files"!

- being a global structure, it defies the information hiding criteria. And, exposes information that can be exploited, misconfigured, etc. Why should I, as a user (which may be a human entity or a program entity), need to know the identities of other UIDs/PIDs on this system (visible in passwd(5), as entries below /home, or listed in ps(1))? Because this is accessible, you must now layer a separate access control system atop it to prevent "users" from seeing or altering selective content. And, control over those permissions is in the hands of the users (to mis-apply, even sysadmins!).

- What does stdin mean to a program that is controlling the temperature of a reaction vessel? Does that abstraction coerce the developer to expecting the temperature setpoint (and other commands) to be issued over stdin instead of some other communication mechanism? Or, maybe stdin should be the temperature *sensed* from the vessel -- and stdout be the control to the heater/refrigerant involved? Does the fact that a "filesystem" (as in datastore) is supported coerce people to use "files" to store data that is most likely *structured*? (a spreadsheet is accessed differently than a log file -- yet both are reified as "files" -- streams of bytes)

- Why should I have to go romping through this global namespace -- likely being accessed, concurrently, with other "users" -- to find those items (and ONLY those items) pertinent to my operation?? Is there an expectation that someone might want to invoke me with /foo/bar/stuff/lightbulb as the target of my control?? (will that "file" have the correct ioctl(2)s?)

- How do I verify that some user (agent) isn't abusing the system? Using more resources than he should? And, his likely *intent* in those (ab)uses? Is he a naive idiot who's made a careless mistake? A malevolent actor? Or, someone with a "job" that genuinely requires such usage?

- How do I DYNAMICALLY ration the LIMITED/FIXED resources available to me to meet ALL of my current obligations? Can I shed some of those? How do I decide?

- How do "I" *measure* my compliance with my operational goals? If I have timing constraints, will I know about them "in time" to adjust my activities to better meet those goals? Or, will I just perform poorly? Be aborted by a user for my failings? (how will I *learn* from those experiences -- do *I* have to track my own performance and consult that "history" each time I am restarted?)

- What prevents me from repeating the same mistakes, endlessly, as a consequence of a bug or misapplication of myself to the "wrong" problems? Do I have to rely on a human being to sort this out and take corrective action?

- The more unrelated/loosely related things I try to do at a time, the greater my chance of doing one or more of them incorrectly (Ah, but you'll be so much more *efficient* as you'll only make one pass through the data!)

- What assurances do I have that the hardware is performing properly? What assistance can I have in validating it? (Ah, if the hardware is faulty, you are absolved of any responsibility for misbehaving!)

- How do I expose the structure of the system so *I* can recollect it AND newcomers can quickly come up to speed on it?

- How do I effect changes? What burden does that place on the user/uses of the system?

These issues are consequential to the model that the OS *imposes* on my designs. They bias implementations in directions that might not be the most efficient, the most secure, the most correct, the most maintainable, etc. What do they provide to offset these compromises??

So:

- no global namespace

- per process namespaces that constrain what that process can access

- capabilities for all accesses (constrain what the holder can *do*)

- fine-grained control over actions accessed via capabilities

- constrain communication paths/interactions to only those that are necessary

- decompose the OS to keep each component focused and constrained to it's need for (specific) privileges

- track resource usage dynamically

- delegate "powers" to actors designed to enforce specific constraints

With this sort of structure, I can define a "task" that is responsible for irrigating a portion of the yard by passing a namespace consisting of:

- Zone (a capability that allows it to access information about the section of the yard of interest and its "watering needs")

- Environment (a capability that allows it to access historical data as to the conditions that the Zone has experienced -- amount of sun exposure, temperature ranges, precipitation, etc.)

- Valve (a capability that allows it to turn on the water supply to that Zone)

- Log (a capability that lets it APPEND a record of its actions to a "history") In addition to other universally accessible objects (like the time-of-day "Clock")

So, it need not be concerned with OTHER zones, their needs, or valves or the conditions that they may have experienced (e.g., the roses are out in full sun but the sage hides under one of the trees).

And, try as it might, it can never access the lock for the front door! Or, change the setting of the house's thermostat! (furthermore, if it tries to resolve the name "FrontDoor", it will abend -- because it was KNOWN when the code was written that it would never reference an object by that name! Can you prevent a particular library from being accessed in one of your binaries? Or, device accessed through the filesystem? (Why is your thermostat trying to delete my home directory??)

What you *don't* immediately see is that these objects might reside on different physical nodes in the system. Yet, you (programmer) don't have to be aware of how to access them. Or, if they *migrate* while they are in use (e.g., the code that "backs" the "Environment" object may have been migrated to another node that had surplus resources available, allowing the node that had previously hosted it to be powered down. Why should your code care about these details? When you access google.com, do you really care which server in their farm accepts and processes your request?

You also don't have to worry about the "level of privilege" that is required to perform these operations. E.g., this program will be allowed to append data to its history buffer -- but, not overwrite previous contents. Or even READ them! Some other program may read -- but not write -- that history to determine how this program performed and advise another program (agent) to revise the Zone constraints ("the roses seem to need more water").

Are you sure you'd get the "permissions" correct for each of these "actors" if they were presented in The Filesystem interface?

If resource constraints prevent the program from meeting its goal in the time prescribed ("deadline"), then the system knows about this shortcoming and can take steps to compensate. E.g., perhaps arrange to schedule the irrigation at a time when there isn't any other competition for the water supply (e.g., bathing, cooking, etc.) An *agent* can then tweek the schedule for that activity without requiring the (human) user to get involved.

All of this imposes extra overhead. But, I can *buy* performance. You can't "buy" reliability/correctness/maintainability without throwing lots of manhours at those aspects ("will it ever be done?")

Pro grade os like Solaris and some of the free bsd's have had fine grained activity based permissions for decades. Even Win NT had acl's in it's day.

If you want to see pro software engineering in practice, look at the Vax VMS internals book, for an old example, or the FreeBSD or Solaris internals books, all of which go into fine detail on design decisions, data structures and far more.

Show me one that does the same for Linux, and while you are at it, take a look at the source code for systemd, a more hacked and trashy bit of code I have yet to see anywhere else.

FreeBSD added *support* for capabilities in 10.0R -- just over

It's a "bolt on" solution -- much like trying to back-port RT to a system designed without that consideration.

It is an OPTIONAL "mode" that applications can use. The most important piece of software in the box -- the kernel -- is not built around them. The *set* of operations that can be governed by them are predefined and apply to standard UNIX operations. E.g., restricting a process from unlinking a file. Or, from dynamically allocating memory.

You can't prevent a process from using specific functions in specific libraries (unless you take those apart and turn them into individual objects).

Other actors don't leverage the capability that YOU used to invoke them so can't act in your name.

They can't be passed to other processes on other machines (you'd have to build a mechanism to form that bridge) to extend your "abilities" to another computing domain. (does your UID even make sense on that other machine?)

Most importantly, the existing *system* -- every process and program -- was built WITHOUT them.

How you approach a design is heavily influenced by the tools/mechanisms you have available (or *select*) to build it. Trying to PREVENT a piece of code from doing <something> on an existing system relies on all sorts of bolt-on mechanisms (e.g., jails, sandboxes, etc.) because the underlying system was designed WITHOUT them.

Despite their being known technologies going back a lifetime!

The texts that have been spared getting chopped up for digitizing include:

VAX Architecture Reference Manual (Leonard) VAX Assembly Language and Architecture (Kapps/Stafford)

(not counting "published papers", etc.)

Please, I do this for a living. :>

The "quality" of a codebase and the design concepts that it is built around are two different issues, entirely. Almost all are monolithic kernels.

Few (none save the 432?) capability based CPUs have been designed in "integrated" (chip) forms. So, its doubtful many people have ever built anything under such systems.

In general, programmers dislike having their hands tied. They *want* to be able to access some other part of a system that, strictly speaking, isn't related to what they are doing. Always in the name of efficiency. (like mbufs for disk and network services -- heaven forbid there be TWO pools of buffers *or* a really fast way of creating MORE on the fly!) Tell them they have to indent by *3* spaces and you'll spend the afternoon arguing the merits of 3 vs 4 vs 8...

And, ALWAYS fall back on the speed/efficiency argument.

In the years I've been writing code and designing "machines", machine cycle times have fallen from 10us per *4* bit operand (e.g., ~20us to add two 8b values) to < 0.25ns for the same operation. That's 5 orders of magnitude. And, you're *still* worried about how *fast* some bit of code is -- enough so to jeopardize correctness, security, maintenance, etc.??

Time to grow up and be a real professional, instead of a "code cowboy".

Not a bad list to start with, but there are many more. Anyway, what are you trying to prove ?. What was the last system that you designed from start to finish, including the hardware, that worked, paid well, and made the client a lot of money ?.

Must be a high flyer, but perhaps need a little more oxygen ?.

As you keep saying :-).

Name them. unix did not kill anything.

I try to avoid ad hom asshole comments like that, just so unprofessional. Obviously someone with a lot to prove, and probably glories and achievements deep down in the past. Getting older and ever more obsolete, not forgetting embitterment. Need to guard against the hardening of the attitudes, bad for the health.

Obviously have a lot of time on your hands, to spend so much time generating acres of word salad, nitpicking over irrelevances.

Rarely the sole criteria, but but can be relevant, trying to satisfy the devil's compromise, of performance, cost and reliability.

How about answering the question ?.

How many do you want me to list? I have a complete set of MULTICS manuals, should I list all of them, individually (the set is several *feet* thick). All of the published papers I've referenced?

I bill at $5K/week for long term projects (year). Double that for short term (month). I do at least one complete PRODUCT each year. AFAICT, all of them have made my clients money.

What's YOUR point?

And you seem to ignore. I wasn't born yesterday. Or, the day before. My first project ran on an i4004 -- were you out of diapers at that time? Any experience with ANY "experimental/novel" systems? Hardware designs thereof?

- MULTICS

- Hydra

- Mach

- L4 (still struggling) Did you fail to read the list of OSs that I presented previously? Ever met anyone developing under QNX? (yes, there are products out there -- but far fewer "designs")

Of course it did! Because people always used UNIX emulation as a criteria for evaluating a new system (look at Mach). Without considering the baggage that UNIX brought to the table.

"How does Blue compare to Red?" "It's not Red enough..."

Today, Windows/Android/OSX put the same "heavy thumb" on the scale rendering other options moot. Regardless of their merits!

It's a common assessment of "coders":

Nope, I've already got a track record. And, a delightful lifestyle made possible by it! So much so that I was able to retire "in my prime" to work on self-funded projects that *I* find interesting.

Gee, talk about /ad hominem/. Yet, *I* am the one talking about interesting operating systems and system designs -- instead of harkening back to Slowaris, UNIX, etc. Gotta wonder who's obsolete in this conversation...

The fact that you consider OS architecture irrelevancies is telling. No doubt a self-taught "coder", eh?

I have no interest in Linux.

You are crossing swords with Don Y, easily our most argumentative sci.electronics.design contributor. Just drop it. He will keep moving the goal posts and he seems to have infinite time.

Did I tell you about that time he ended up suggesting fridges should detect burglary attempts, just because I argued that a temperature setting in degrees was more useful than a dial going from 1 to 5?

Jeroen Belleman

=======

(Concerning the original subject, I use xfig with export to .eps. For plots, I use gnuplot and do 'set terminal fig' once I'm happy. That way I can still apply some finishing touches before exporting to .eps.

If I had to start over, I'd now probably choose inkscape and svg as the pivotal format, but I'm content with xfig, so why would I change?)

So what, used to have a complete orange wall on RSX, a complete grey wall on VMS, a blue wall on RT11, but what does that prove ?. Took up a lot of space was given away. But anyway, list them all, and a link to pdf online, so we can all see them. Internet Archive is pretty good for stuff like that.

Sounds wonderful, so how do you find the time to make so much noise here, every day ?.

I do tend to question those bellends who shout, and throw toys out of cot, but perhaps I have misjudged you ?.

You do seem to assume that everyone else is stupid, which is a dangerous assumption, because however bright you think you are, there will always be others who are more so, and have more experience.

From what I remember, QNX formed the backbone os of Blackberry phones, which sold millions. Never used it here, but have worked on perhaps half a dozen others. Some didn't look anything like unix, perhaps predating more general use. Fact is, all os's need to provide the same sort of basic functions, so it's no surprise that most os's have tended towards that as a baseline.

You still deflect on answering the claim about unix, so assume that you must have no ideas as to how a basic os should be structured, for whatever reason. Pages of word salad, deflecting and butterflying all over the place don't cut it, so how about some real science, for a change ?. (In a paragraph, if possible :-).

Heresay only, and most who actually have well stocked track record, would never need to shout about it. Thus, some doubt as to veracity.

Os design has been of interest here for decades, like you, have built quite collection of books on the subject, but that doesn't prove that either of us have learnt anything from them. Could just be shelf Queens.

Well, you seem to be talking a lot, but not saying anything. What factors would you consider, that have been "squeezed out", by unix, and prevented os progress. Please be specific and provide some detail.

That at least, makes s sense, though it does have its uses.

Probably right, but perhaps a useful adversary to sharpen up argumentative skills, and question own assumptions.

Don't get much time for usenet these days, but good to see that all the usual suspects are still here.

Chris

I've sent many to AEK, some to Roger Roach (who is/was trying to find homes for *his* collection), some to the local library, etc.

I'm downloading and uploading content and interacting with my colleagues -- which happens at various times throughout the day, based on our individual needs (none of us like telephones) as we are all in different time zones and have different work schedules. I can also "add attachments" instead of trying to verbally describe something.

I can "make world" or run a symbolic analysis of a section of code (both time consuming activities) while attending to other things -- instead of twiddling my thumbs waiting for a machine to finish.

I regularly engage with people who may or may not be "smarter" than me but who have information from which I can learn. I spent almost 40 years planning this project -- deliberately developing the skills that I would need by selecting client projects that would foster such efforts. Each skill required finding an avenue for it to be developed "in the wild" instad of "hypothetically".

There are many different ways to provide services to an application (programmer). UNIX closed the door on variety with its "single namespace, everything is a file" approach. Despite better options existing BEFORE its inception and since. It's amusing to see bolt-on approaches to back port those features (a belated acknowledgement of their value -- too late to have helped previous designs)

Now, folks build products on (e.g.) Linux when they would likely NEVER have enumerated its capabilities as *requirements* in their designs. Again favoring one offering over technologically better offerings.

I stated UNIX rendered many OS's, that were technically more advanced or capable, obsolete. This, not because UNIX was the superior choice but, rather, because it was the simpler, more available, faster (cowboy coders) and cheaper choice. Even Ritchie and Thompson conceded as much in their impatience to wait for MULTICS.

I gave specific examples. You can look at their histories and see what they listed as their "failings".

I write a new (RT)OS for every project. This is relatively easy as the basic issues are the same (how to do a context switch, protect atomic regions, schedule threads, etc.)

It lets me see, firsthand, the value of different types of abstractions at the API level. And, the limitations that a particular approach places on an implementation.

So, when I have a new set of requirements that are best suited to be implemented *in* a project's OS, I already know which approaches to try -- and avoid.

Current systems are insecure and bloated. Witness the number of continuing bugs reported in them. They cling to the same model ("everything is a file") despite its irrelevance to the project at hand (what's a "file" in a process control system? the air handler? reaction vessel? or, in an automobile? should each headlight be a file?). Because people would rather cling to something that exists (regardless of its shortcomings) than create something more appropriate.

Ah, we can blame it on Management and the schedules they set...

Linux makes sense in a tool that someone has already created that can be applied to a particular problem. E.g., I use CZ extensively despite being able to perform the same actions, serially (taking care not to miss any detail), from the command line.

I've run NetBSD since 0.8; FreeBSD since 0.9 (though abandoned it to concentrate on NetBSD as my primary software development platform at FBSD 2.2R). I rely on some Windows-based tools and some Slowaris (on an SB2000) to validate my portability goals. I will *deploy* on Arm (Am623) but won't commit to hardware until all 22 of the current designs are ready for release.

I.e., I *tolerate* the issues Slowaris raises, Windows raises, BSD raises, etc. -- because they are necessary for me to craft my design. But, that doesn't mean I would embrace any of them *in* that design (as they don['t support the abstractions and mechanisms that I need, as I've described in the "salad" you've eschewed)

You will find that most people have very narrow ranges of knowledge and often quite "shallow". Discovering this shortcoming in engineers is particularly distressing.

I was gifted some Borland software in ~1990 -- by a woman who had received it as a "bonus" with a computer she had purchased. Among the items was a copy of Paradox (DOS) 4. As I am always interested in expanding my horizons and skillset, I saw this as an opportunity to reorganize my (paper!) address book.

I was amused to discover that none of my "technical" colleagues had every built or used a database. Some had resorted to "big spreadsheets" that they could manually search/peruse. But, nothing that afforded ACID or the structured interface.

I eventually sorted out how to build a suitable schema so I could "chase relationships" through the data to get to a person of interest (Bob's Wife's Brother lives on the same street as the guy that I met at Bob's party, last year; what was his name and contact information?)

And, with a few thousand entries, performance was never an issue -- even on a 486. And, I was already more of an expert than anyone that I *knew*!

When I built the schema to track the files that I have on the various media, here, it was relatively trivial: Paths: big serial ID text Name big integer ContainerID

Meta: big serial ID big integer PathID big integer Size md5hash Hash (knowing to break out the meta information from the path being a good observation as containers don't need those!)

This, superior to trying to encode entire pathnames in a database with insanely wide text fields to accommodate.

So, /root/me/ReadMe might result in the following Path entries: 1, **TOP**, 0 2, Disk9, 1 5, root, 2 8, me, 5 9, ReadMe, 8 and Meta entries: 382, 9, 4233, 0x095820394820394823098...

Note that /root/me/archive.tar might augment the Path table with: 15, archive.tar, 8 22, folder, 15 (!!!!) 26, file, 22 31, another, 22 if the archive contained folder/file and folder/another (i.e., an archive is a container in much the same way that a directory/folder is).

And, if the "file" in that archive happened to be a (likely) duplicate (intentionally or coincidentally) of /root/me/readMe, then there would be a Meta entry of: 699, 26, 4233, 0x095820394820394823098...

As such, if I lost "ReadMe", I could find a duplicate of it by searching for Meta entries that have the same Size and Hash values as it had and then reconstructing the location of the item from it's associated PathID.

This is likely how you would structure such data in a program, using pointers for the XXXXX_ID members. The RDBMS is already designed to do this effectively.

But, now you're talking (many!) MILLIONS of records and the time required to locate particular entries (SELECT FROM...) becomes an issue.

Suddenly, I understand the skillset that a DBA must hone as those sorts of datasets and and queries are running constantly and their timeliness is an issue for that environment.

Of course, no one would even try to manage this data in a spreadsheet or "flat file" (with 300K lines/records?); instead, they'd use find(1) on a live filesystem and "hope".

Using real world problems is a much better teaching aid than just a toy application used by the tool manufacturer as an aid in teaching.

I used this anecdote as we (colleagues and I) are currently debating how to organize a "music database"; i.e., what is the data model that needs to be codified in the schema (keep in mind that different artists might perform the "same" song, in different ways, on different media, etc. And, that a particular performance might appear on different media. Or, with a different cast of performers in a group that's membership has evolved over the years, etc.

I.e., it's not a simple problem. And, you can choose to ignore it (and any problems a chosen implementation manifest) by easily claiming "good enough".

Aside from the things others have suggested here, such as Inkscape and TikZ, I’ve often found that it’s useful to use diagram-type-specific diagram software.

For node-link diagrams, it’s usually a lot easier to use Graphviz than to draw them by hand; for example:

Graphviz is quite a bit more flexible than it may appear at first, but as you stray further and further from its core competency, it becomes harder and harder to get the effects you want. There's a gorgeous gallery at

And obviously for schematics you can get decent results much more easily with a schematic-drawing program like xschem than with a generic drawing program like Visio (or MacDraw, which is what Horowitz & Hill used to produce the best-looking schematics I’ve seen). Unfortunately both LTSpice and KiCad produce schematics that look like dogshit.

My guilty pleasure is producing schematics (and waveforms!) in circuit.js, whose results look much less terrible than LTSpice, but not as good as I’d like. For an example from a week ago,

Circuit.js can export SVG, like Inkscape. You can use its “undocked scopes” to include simulation waveform results in the output SVG, but be aware that they are not quite invariant with zoom. An SVG exported from the above-linked circuit simulation cuts off some of the text in the scopes, has waveforms obscured by text in others, and weighs 81 kilobytes.

Apparently it’s reasonably easy to incorporate SVG in LaTeX now. \usepackage{svg} and \includesvg{foo.svg}.

Writing SVG by hand in a text editor is also a reasonable thing to do; in recent years it’s largely displaced PostScript for me for that purpose, being more readable, terser, and better supported by things like browsers (and Inkscape). For example, this is a red arrowhead:

Kragen