Systemd Now Has More Than 1.2 Million Lines of Code (phoronix.com) 249
This week Phoronix marked a very special anniversary:
Five years ago today was the story on Phoronix how the systemd source tree was approaching 550k lines so curiosity got the best of me to see how large is the systemd Git repository today. Well, now it's over 1.2 million lines.
After surpassing one million lines in 2017, when running GitStats on the systemd Git repository today it's coming in at 1,207,302 lines. Those 1.2 million lines are spread across 3,260 files and made over 40,057 commits from nearly 1,400 different authors... So far this year there have been 2,145 commits while last year saw 6,245 commits while 2016 and 2017 each saw less than four thousand commits total. Lennart Poettering continues being the most prolific contributor to systemd with more than 32% of the commits so far this year.
After surpassing one million lines in 2017, when running GitStats on the systemd Git repository today it's coming in at 1,207,302 lines. Those 1.2 million lines are spread across 3,260 files and made over 40,057 commits from nearly 1,400 different authors... So far this year there have been 2,145 commits while last year saw 6,245 commits while 2016 and 2017 each saw less than four thousand commits total. Lennart Poettering continues being the most prolific contributor to systemd with more than 32% of the commits so far this year.
So? (Score:4, Insightful)
It's a large project. Duh. Or are we still stoking the systemd hate fire in 2019?
Re:So? (Score:5, Insightful)
because $current_year has no bearing on the legitimate complaints because none have been addressed.
Comment removed (Score:4, Insightful)
Re: (Score:1)
Most of the original complaints were and still are unmitigated bullshit. For example, the logs are binary because it makes easier to search / filter / secure / tamper proof them and if you want text logs you just set up systemd to log to a text file. The arguments are all that stupid for the most part.
Re: (Score:2)
Thats the part really smart computer people got thinking about a long time ago.
Do the one task well.
Re: So? (Score:4, Interesting)
If any of that was true, companies like SUSE that have been shipping systemd as the default on our enterprise offerings for years would be flooded with service requests from angry users. We simply arenâ(TM)t. Systemd as we are using it today is rock solid and enables many use cases like our transactional MicroOS with read-only filesystem that would be very hard or impossible to implement without it.
Re: (Score:1, Interesting)
I think you're suffering from survivor bias [wikipedia.org].
Enterprise systems tend to be a whole lot more homogeneous and tested than the general population. There are also a whole lot more redundancies built into the entire system (fail-overs, etc) which probably saves systemd from itself *alot*. The general population does not have these luxury items, and as such get the full experience of systemd.
Re: (Score:3)
If any of that was true, companies like SUSE that have been shipping systemd as the default on our enterprise offerings for years would be flooded with service requests from angry users. We simply arenâ(TM)t. Systemd as we are using it today is rock solid and enables many use cases like our transactional MicroOS with read-only filesystem that would be very hard or impossible to implement without it.
That word... Stick with "very hard". That one is good. But don't use that word.
Re: So? (Score:4, Interesting)
Not sure you got it: Iâ(TM)m working for SUSE and I know we are not flooded with service requests about systemd. To the contrary. Migration was really smooth. And this is for a Linux distribution that is offering in-place updates from previous versions.
As for the increasing size of the project: This is not just what is typically perceived as the systemd init system, but includes a lot of code like udev that used to exist separately on a pre-systemd Linux and was just merged into the systemd project for maintenance reasons. Thereâ(TM)s virtually no bloat as in adding yagni features.
Re: systemd -- another brick in the wall (Score:2, Interesting)
You didn't hear complaints about systemd because people got tired of talking to a wall. As it continued to move forward, and old ways were tossed aside, those who had existing working systems were told they were no longer supported. When people asked why things were not done with a compatibility abstraction layer they got stone silence. Options to insulate different functions from each other were killed. Instead, more and more got pulled into systemd, and now if you want to run any thing on suse, you ar
Re: (Score:2)
You never got service requests because systemd is not able to boot these affected systems and they're all sitting at a rescue shell. ;-)
Re:So? (Score:4, Informative)
Interesting. Modded Troll for pointing out that systemd isn't the only init system out there and that alternatives are backed by major players. Moderator educate thyself https://en.wikipedia.org/wiki/... [wikipedia.org] or hand back your mod points. They belong to impartial viewers not some fanboy of a replaced system.
Incidentally from that list there is an interesting standout. I mean I think replacing the init system was possibly the very first thing Apple did when working on a BSD version of MacOS (launchd) and it had a very similar scope to Systemd.
Re: (Score:2)
Have any audits been completed? Or are we using the many eyes argument?
Re: (Score:1, Funny)
I really appreciate the support for HEVC and x264 hardware assisted decoding
and encoding provided by the latest systemd in "stable." There's talk about merging
with pulse audio, but there has to be buy-in from the original pulse audio developer,
and I hear he's very polarized and difficult to work with...
CAP === 'dissent'
Re:So? (Score:5, Insightful)
Re:So? (Score:5, Funny)
systemd is like the Borg. Eventually, it will assimilate the kernel, all gnu utils, and X.
Eventually Systemd and Emacs will have to fight it out. I'm betting on Emacs for the win.
Re: (Score:3)
...
And ed doesn't waste space on my Timex Sinclair. Just look:
-rwxr-xr-x 1 root 24 Oct 29 1929
-rwxr-xr-t 4 root 1310720 Jan 1 1970
-rwxr-xr-x 1 root 5.89824e37 Oct 22 1990
Re: (Score:2)
Ed, man! !man ed
And ed doesn't waste space on my Timex Sinclair. Just look:
Emacs can emulate Ed and Vi (and a bunch of other editors) ...
Re: (Score:2)
Re: (Score:2)
It's a large project. Duh.
That is the whole problem. An init system must be small and compact, otherwise it cannot be reliable and secure.
Re: (Score:2)
SystemD Derangement Syndrome (SDDS) is a real thing here.
I thought at first it was just lazy sysadmins who didn't want to learn it or move to a distro that doesn't use it.
Now it seems much more apparent that it's lazy sysadmins who want to tell other people how to run their systems. They hate competition because they Know Better. It's the worst kind of will to power as they are very unlikely to be contributors to the bash-based distros, which definitely have their place and value.
You'll see one above clai
Re: So? (Score:1)
Lennart Poettering continues being the most prolific contributor to systemd with more than 32% of the commits so far this year.
It stokes itself, apparently
Re: (Score:2)
Project goals can shift. PHP for instance was never intended to be a new programming language - it was just a form processor for CGI scripts. The language feature emerged as a need later on.
Systemd is kind of a pile too. I don't like the binary logs, and I think it's a security disaster waiting to happen. But the services it provides have also emerged as things that have been sorely lacking fron SysVinit for the longest time. Poettering rewrote init, then proceeded so implement things he needed for his new
Re: So? (Score:5, Informative)
What's lacking? What can the systemD init do that we didn't have? Other than maintainers not having to keep track of scripts.
So it made one group of developers jobs easier, while fucking the rest of us.
I'll bite. It's event driven. Let's say your laptop falls asleep on the corporate network and you travel to a hotel and wake it up. How will your laptop know what to do with SysV? What you write a container on your local server. You close it and move it to Amazon E3 cloud. Explain how this wouldvwork will static SysV and not break? SystemD makes it possible for these scenarios to happen. At&T Unix systemV was designed around a mini computer in a MDF. Not dynamically cloud based on a variety of different places and conditions
Re: So? (Score:4, Insightful)
I'll bite. It's event driven. Let's say your laptop falls asleep on the corporate network and you travel to a hotel and wake it up. How will your laptop know what to do with SysV? What you write a container on your local server. You close it and move it to Amazon E3 cloud. Explain how this wouldvwork will static SysV and not break? SystemD makes it possible for these scenarios to happen.
Shouldn't those events be handled by another process/service than the process that spawns all other processes? Any issues (timeouts, memory corruption, bad lines of code) take out the entire computer. Just reboot? SystemD may be solving a huge problem/set of problems, but it is introducing as many as it solving.
For myself, I don't have a need of a solution to those problems because I would just turn my computer off and then turn it back on in the hotel room.
It is the architecture that is the problem, not the code or the ideas.
Re: (Score:1)
It was supposed to be an init-system.
It is supposed to be an init-system that eliminates the need for bash scripts. Everything is either a config file or a binary executable that hooks directly into the same places that all the single purpose command line tools used to. With no scripts needed to manipulate or generate command line parameters. Back when it was a gleam in a few peoples eyes, the description of systemd's benefits were principally "No more shell scripts". And if someone had an unusual startup problem and a comment was made, "Just
Re: (Score:2)
No more unnecessary forks,
What's wrong with forks? It's not like this is an on-going thing while running. Once the daemons are started, you get all the temp process ids back*. And if you librarize simple commands, you move the complexity of systemd into the shell interpreter. It's actually not a bad idea for commonly used commands used a lot once the system is up. But probably not worth the work for command line stuff used primarily at startup. And again, this may not be possible to achieve with narrowly used utilities that are por
Comment removed (Score:3)
This is why I don't like systemd (Score:5, Insightful)
Can you imagine:
- working in a small startup company,
- making a product which sells into large industrial corporations
- who use it for mission critical infrastructure
- when that product includes a component that runs an embedded OS,
- which contains a necessarily privileged core sussystem
- which is over 1.2 million lines
- and growing at 275 lines per day
- and trying to do a security audit on it?
Re: (Score:2)
Can you imagine: *snip* working in a small startup company *snip* and trying to do a security audit
Nope, because I'm sure that never happens.
Re:This is why I don't like systemd (Score:5, Insightful)
All developed in Rube Goldberg-style. They built a giant hammer, and now everything looks like a nail. Each time they clobber another nail, they call it proof that they need to build the hammer bigger.
Re:This is why I don't like systemd (Score:4, Interesting)
Actually they built a Dremel. A multi-functional rotary tool which replaces a lot of dedicated separate tools and is far more useful for a general case. Every time they see a use case they release another attachment to bolt on the end. What this resulted in is something hugely popular, not perfect for every scenario but damn good enough for most.
Re: (Score:3, Interesting)
I have yet to encounter a use-case for which systemD is an improvement over init. I'm not saying they don't exist, but I've never encountered one. And I've encountered more than two for which systemD is considerably worse.
Re: (Score:2)
Re: (Score:3)
I have yet to encounter a use-case for which systemD is an improvement over init.
That is probably because you have a narrow definition of the purpose of init and you actually believe the system state should not reflect the current hardware state, should not be event driven, should be executed purely linearly, and that additional management of daemons should be the result some other daemon management system not running PID 1, and the entire mess be handled by scripts with an endless amount of copy pasted bash code.
Personally I believe the opposite which is why I find SystemD to be a rath
Re: (Score:2)
Maybe he's running Linux in servers in secure a data center where hardware changes only take place with controlled and audited processes, and therefore all of the things you mentioned about the 'current state of the hardware' is not relevant.
If you find that SystemD is a 'massive improvement', then I can only assume that you do not professionally manage servers, especially servers for third parties.
Not everyone uses Linux on a laptop or desktop.
Re: (Score:2)
Actually, these days I mainly use Linux on my personal desktop. But there still aren't any hardware changes that I don't manage personally.
Re: (Score:2)
The problem is that they needed something to hammer nails and, as you say, built a Dremel.
Re: This is why I don't like systemd (Score:2)
Re: (Score:2)
Yea, but only finishing nails.
Re: (Score:2)
I was only slightly making reference to it for a reason: https://www.youtube.com/watch?... [youtube.com]
Re:This is why I don't like systemd (Score:4, Interesting)
As engineering director at a large interconnect in the mid 90's I made a key decision to put a GNU/Linux server in a mission critical piece of infrastructure for the then new Alaska Native Medical Center, in Anchorage. I fully appreciated lives were at stake, and in fact lives were lost, not from this, but from another vendor who chose to use NT for the hospitals medical paging system, which, from my experience while I was there, was frequently down. In fact, the only "issue" I had with our reliable server, hence it's long uptime, was being an early discoverer of the Jiffies overflow bug.
Would I feel comfortable making the same decision today using any systemd distro? Based on my own experiences with systemd since its introduction, the answer is clearly NO. Would I feel comfortable to do it with another distro that did not have systemd (Alpine, Gentoo, Devuan, ...)? Yes, I would feel comfortable doing that, or using BSD. Along with the code, the issues with systemd since its introduction have not shrunk, but also continue to grow. If I could not have trusted it for that mission if it had existed then, how can I trust it for anything now?
Re:This is why I don't like systemd (Score:4, Insightful)
No, they aren't. Managing critical systems is about understanding and mitigating risks and hazards. In this regard, systemd's state and consequent behaviour at runtime is largely unknowable and unprovable, even to the systemd developers. Its internal graph of units is hard to get at, and the exact internal state is not directly queryable. The system as a whole has so many individual tightly-coupled parts, that it's difficult, if not impossible, to know and guarantee behaviour on state changes.
If you compare this with sysvinit, the state is limited to the current runlevel plus the inittab rules used to respawn services. You can understand the current system state at a glance, and the behaviour on runlevel change (not that this would happen when the server is running) is easy to follow step by step through the sysv-rc script and the subsidiary scripts as they execute. There is complexity here, but it's directly accessible and observable. You can validate it is operating correctly and will continue to operate correctly.
Re: (Score:3, Insightful)
What I find incredible is that it's apparently so terrible, yet no-one has been able to make something better that gains any real traction among the major distros.
Poettering brushes off serious security problems, many people seem convinced that the entire concept is flawed and makes Linux unstable and their lives as admins a nightmare... Many claim the old bunch of shell scripts system was better. Yet... There is basically zero competition. Almost every distro uses it.
Re:This is why I don't like systemd (Score:4, Insightful)
Re:This is why I don't like systemd (Score:4, Insightful)
Also, Red Hat has a lot of money compared to its competitors. Ubuntu/Canonical might have been a Red Hat competitor once upon a time but they didn't... focus their energies very well.
Also, graybeards refuse to acknowledge the importance of use cases that don't matter to them or see the flaws in the system they're so accustomed to, so progress on alternatives (e.g. OpenRC whatever) remains niche.
Re: (Score:2)
--The guy that runs Distrowatch has been active for the last year or so patching up SYSVinit code. I supported him on Patreon for a while:
https://www.patreon.com/sysvin... [patreon.com]
275? I am guessing you don't do this for a living (Score:1)
Doing a security audit on it? Yes, I can inspect 275 lines in 2 minutes if they're simple and 10 if they're the most complex I've ever seen. 2-10 minutes per day is not that hard, especially with the help of automated tools.
To be clear, I am not defending systemd. I don't have a dog in the fight. However, I can't believe a professional would
Re: (Score:2)
Re: (Score:2)
However, I can't believe a professional would complain about this many lines of code.
They're not complaining about the general speed of Linux development. They're complaining about a core operating system component that keeps growing. That's not supposed to happen. Core components are supposed to stabilise and level out, and then development moves to building non-core things on top of it. A core that keeps growing is not really a core.
Mind you, I'm just explaining what the complaint is, I don't have enough information to make the call if it's valid or not. If those 275 lines are being ad
Re: (Score:2)
No, I can't. I do actually work in such an environment, and there are specialised embedded RTOSes for this purpose. No systemd, and no Linux. They are simple, compact, and secure.
Re: (Score:3)
Instead of "do one thing and do it well", we have massive monolithic code
People get their pants in a knot because systemd doesn't follow do-one-thing-and-do-it-well, yet seem content enough to run the monstrosities that are modern web browsers. One may argue that a large portion of the OS resides in the browser nowadays, but nobody seems remotely as angry about it as they are with systemd.
Amusing...
Re:This is why I don't like systemd (Score:5, Insightful)
Re: (Score:2)
Umm, 'scuse me, but does systemd run at root privileges? I'm guessing, yes. And does your web browser run at root privileges? I'm hoping for an emphatic NO on that one. If so, then I'd say there is a world of difference right there. Sure, the web browser is too fat and monolithic, but I'm not going to get too puffed up over that because, well, it's supposedly kept in check by the system...
But systemd, at millions of lines of code and running at the highest privilege levels possible... That sounds like a red
Re: (Score:2)
Does your web browser run gmail and facebook as different users? I didn't think so. In many ways, your user account is the root of your computer.
Expecting "the system" to keep anything in check is naïve. If your web browser is compromised, and you're not running it in some kind of jail (which you're not, because who is?), then the attacker has access to all the files that your current user has access to.
Re: (Score:2)
While I do agree that the kernel is somewhat bloated, in practice you're only running a small fraction of that total code size, because the vast majority is drivers for hardware you don't own. It never gets used.
Re: (Score:2)
I'm not defending systemd, I'm highlighting people's inconsistent reactions to two different projects blighted by bloat and feature creep.
Sigh. (Score:5, Insightful)
And yet it's entire purpose was to replace a handful of readable shell script files that you could fit in a handful of Kb.
Re: (Score:1)
Mission creep, it's everywhere. By next year it should have a window manager and a media player
Re: (Score:2)
--Oh come on, then it will be competing directly with Emacs :P
Re: (Score:2)
Well, like version 1 of Windows 2000 ... the one that convinced me to switch everything away from MS.
Re: (Score:1)
Re:Sigh. (Score:5, Interesting)
Re:Sigh. (Score:4, Insightful)
I think its purpose was to drive a wedge between applications and the kernel
No it's purpose was to replace the many existing wedges that already existed. SystemD has done nothing at all to separate applications and a kernel which wasn't already implemented (existing networking tools, existing event based hardware management, existing login systems). The most you can argue is that it created an abstraction through a universal implementation of cgroups, but that was the end goal of the kernel team not of systemd itself.
Linux is perfectly usable without it. Just go and maintain the hundreds of wedges that already existed.
Re:Sigh. (Score:4, Interesting)
I did for years. Since systemD showed up, I've pretty much given up. Now if there's a problem, reinstall is the simple solution. And it works as often as anything else. Just make sure you have current backups.
Re: (Score:2)
Systemd massively simplified the amount of configuration and re-installing your system would just result in the same code base. At some point you should just bite the bullet and read the manual. It'll be faster.
Re: (Score:2)
cgroups could have (and probably have) been used by any init script once they were in the kernel.
Utilising new kernel functionality is not a reason for a *different* init system. Just a small upgrade to the one you already have.
Re: (Score:2)
Indeed they could have. Because that's exactly what we want on our system, every application running and managed in a different way without any consistency at all. /sarcasm.
In all seriousness though the Gnome team did their best to at least make systems which used GDM behave in a sane way once some init script handed the keys to a service that is actually capable of of managing the system rather than scattershotting it to life with bash scripts. But you know what they did? They said "Oh god thankyou, finall
Re: (Score:2, Interesting)
Can anyone explain why its a caching DNS server now?
Re: (Score:1)
browserd needs it
Re:Sigh. (Score:4, Interesting)
Because otherwise Linux systems don't get end-to-end DNSSEC support.
Re: (Score:2)
Great. What does DNSSEC have to do with managing the order in what programs are executed?
Re: (Score:1)
and everything else that lives in "/etc/" configuration files.
So, a Windows registry for Linux. I don't like where this is going.
Re: (Score:2)
Depends on what you mean. I know some Apple ][ games had what could be called a GUI interface, and I suspect some S-100 programs did before that. And I'm ignoring mainframe predecessors, because all I know is that they existed.
SystemD is excellent for RedHat (Score:4, Insightful)
Such a monstrously complex system is fantastic for RedHat's services business. It'll have problems all the time, and customers will need help from the preeminent experts on systemD - RedHat engineers.
I am glad there's at least one a very popular distro with systemD disabled: MX Linux.
Re:SystemD is excellent for RedHat (Score:5, Insightful)
Such a monstrously complex system is fantastic for RedHat's services business. It'll have problems all the time, and customers will need help from the preeminent experts on systemD - RedHat engineers.
I am glad there's at least one a very popular distro with systemD disabled: MX Linux.
Yes Red Hat sell support, but they don't want to be firefighters. They want to help you set up the system and then be available if something goes wrong without anything actually ever going wrong.
I've done support on mission critical products before. No one is going to cancel their RHEL support contract for their mission critical system because it's never broken, people will cancel their support contract if it keeps breaking and they no longer trust Red Hat to keep it running.
Now Red Hat is probably responsible for some of the extra complexity in SystemD but again, I don't think that's malicious. The last thing you want it your customer to think your system is so complex that they're reliant on you. You want to be an insurance policy, not a babysitter.
The reason SystemD is complex is because it has a lot more capabilities, and the reason it has more capabilities is because Red Hat's high paying customers keep demanding more capabilities, so Red Hat delivered.
Disclaimer: I did an internship with Red Hat years ago.
Re: (Score:2)
> The last thing you want it your customer to think your system is so complex that they're reliant on you.
This is complete bollocks. The business model for Microsoft, SAS, IBM, Sun, Cisco and others revolves around this, and the reliance extends to training and certification even for your own staff, and hiring Professional Services for anything more complex than changing a config element.
I'm a fan of basically none of those companies, but again that's not their model.
Their model is to write software that does really important stuff, the certifications are there because so that when the customer goes:
"This thing is hyper-critical and we don't want to call you every time we touch the system. How do we find someone we can trust to administer it?"
They can answer, "It's simple, just hire someone with this certification!".
It's the same reason you get a certified electrician to wire your building,
Approaching usability... (Score:1)
I'm waiting for them to add a hypervisor, distributed parallel filesystem, machine learning module, and Vulkan 3D renderer.
Re: (Score:2)
And soon, email [catb.org].
I am waiting until (Score:3)
Just my 2 cents
It makes business sense (Score:4, Interesting)
Re:It makes business sense (Score:5, Informative)
Remember when systemd was just a chess program? (Score:1)
It's gotten 2415 times as bloated since then!
So... how long... (Score:2)
... before the Linux kernel is merely a task running under systemd? Or even necessary if, as one poster has already suggested, the OS has moved into the browser? Of course, that's BS. But then so is an init system that requires 1M+ (and growing) lines of code.
Init (Score:2)
It has 1.2 millions of code ? God.
Talk about mistakes.
So, what is he doing? (Score:2)
Lennart Poettering continues being the most prolific contributor to systemd with more than 32% of the commits so far this year.
That's a lot of activity for a guy who's default response is: NOTABUG WONTFIX
Relative size of the systemd components (Score:4, Interesting)
$ du -h . | grep M
2.2M
1.3M
1.9M
1.4M
2.3M
2.9M
1.1M
1.5M
22M
And
Great OS (Score:2)
Does great Linux emulation too. Now only if it didn't come with a crappy startup daemon
When systemd becomes self-aware we're forked (Score:1)
... the machines win
Playing with fire (Score:2)
False Dichotomy (Score:2)
Not using systemd does not automatically mean use sysvinit.
I just wanted to point that out.
So many arguments for systemd seem to be "it does X which syvinit does not" or just "sysvinit is soooo old". So what?
There are many init systems. Use the one that fits you best. It might not be systemd OR sysvinit.
Personally, I like openrc. It has features sysvinit lacks such as parallel startup and service dependencies. It does everything systemd does that I myself would actually use. So I will stick with openrc as l
Pointless Verbosity (Score:2)
Why does systemctl require .service at the end of a service name. What the hell else would one be starting or stopping via the init system besides a service? Or, actually a daemon because this is not Mickeysoft Windows.
Yes, I know it sounds like a petty thing to complain about but excess verbosity seems to be a plague that infects all things computer related. Just look at pretty much every xml protocol and if you don't see what I mean there you are probably part of the problem.
It might not be terribly impo
.....and (Score:2)
...its still a piece of crap.
Just adding code can't make a fundamentally shitty idea better.
Re: (Score:2, Insightful)
Re: (Score:2)
You are welcome to send your patches.
Re: (Score:2)
Since when does Pottering have an influence over kernel patches?
Re: (Score:1)
Maybe we'll find out who's really paying for it.
Re: (Score:2)
Indeed. I bet that is the intent. This jerk is trying to write himself a monument.
Re: (Score:2)
Some people still remember. They still produce good software. But look, for example, at the monsters modern "Web Frameworks" are, where you pull in hundreds or thousands of dependencies (all of which can break you software and many of which can break your security) and you see where this mess comes from: "Coders" that do not understand complexity and do not respect it. All they produce will eventually have to be thrown away because it cannot be maintained. Systemd is no exception.
Re: (Score:2)
Some people still remember. They still produce good software. But look, for example, at the monsters modern "Web Frameworks" are, where you pull in hundreds or thousands of dependencies (all of which can break you software and many of which can break your security) and you see where this mess comes from: "Coders" that do not understand complexity and do not respect it. All they produce will eventually have to be thrown away because it cannot be maintained. Systemd is no exception.
I've seen many migrations the other way, where they rip out a DIY system and replace it with a COTS/generic solution because the company is spending tons of money maintaining custom code. That means absolutely nothing comes free and no developer or user ever has any prior experience and the code is custom tailored to the original use case but all the assumptions behind the simplifications and optimizations become a burden if you're trying to change it. Very often it'll fail in ways that are unexpected if yo