evol262

You can do this with pretty much any tool you want. I also did it about 10 years ago with livecd-iso-to-pxeboot (and running from the generated initramfs)

Primary obstacles in 2018 are primarily the lackluster support for ro root filesystems. CoreOS/Alpine are fine. Writable memory filesystems are fine.

CoreOS is not even a little bit dead inside Red Hat after the acquisition. If you're not paying attention to the news from Fedora, CoreOS is alive and well, which says a lot about how it will go downstream.

The IBM acquisition is not final yet.

Nobody is obligating app developers to support umpteen versions of iOS.

There are 2 possibilities:

1. Users who want to stay on old versions without access to the newer app store stay. This happens all the time with people who have old iPads they want to hand off to their kids/grandparents/whatever.

2. Apple stops pretending that there are enough new features every year to merit a major version of iOS, and gates updates for newer packages to only users of the newest phone. They already have the capability to do this for iPads, iPhone X, and others.

iOS is ultimately composed of a bunch of separate packages.

Is there a good technical reason why a fix to their crypto library couldn't be backported?

This is exactly what Red Hat does, and Debian stable, and it works.

I guess we agree to disagree. I just don't like calling them the "other" Romans, or even referring to them as the Byzantines who were carrying on the torch, when they never considered any such thing, and would never have referred to themselves as such.

Then again, despite being an engineer by trade, I'm a historian specializing in Late Roman Antiquity (specifically, the Eastern Empire from Leo the Isaurian to Alexios I, so I'm probably a little pedantic about it.

I commented elsewhere, but Roman culture was distinctively not Greek. The Romans valued virtue, filial duty, martial strength, etc. While the Eastern empire gradually became more "Greek" (in the same sort of cultural syncretism which "Sinocized" the Ming), this wasn't true of the Romans as a whole.

The Goths in Rome explicitly modeled their state after Rome, to the point where they considered the Western half to have survived. The organization of early Frankish kingdoms is a direct result of Roman estates, as experienced administrators were all... Roman. Rinse and repeat. It's not so much that it "informed" their institutions as that dux->duke, because they were the same position, and Diocletian's dioceses obviously survived as organizational units, along with Diocletian's organization of the empire (of which feudalism is a direct result).

During the Renaissance, ideas of liberty and democracy aped the Romans, but none of this was a cargo cult, as the ideas spread in the Renaissance drew directly from Roman historical sources (including arguments for why they did/did not work) rather than any cargo cult mythology.

The "Byzantines" WERE Roman and always called themselves such. They were the "Rum" to the Turks because they called themselves Roman.

I'm not sure how a state which can trace a direct lineage of law and rulers back to Romulus is "carrying the torch".

I mean, not really. The Romans, as always, picked and chose the parts they liked and integrated them into their own mythology. The Roman pantheon was a superset of the Greek pantheon (among others), as evocatio was used as a final part of conquest. The Romans also stole the gods of their foes, and more than just the Greeks.

Roman culture, though, was heavily focused on superstition and virtue, rather than logic, and is not in any way a retread of Greek culture.

I'd disagree that the Romans had more in common with the Middle East than northern/western Europe purely on the basis that a substantial part of the feudal organization, religion, and law of northern/western Europe comes directly from the latter Empire. That's unfair as an argument, because we don't really know what was there before that (lack of Celtic writings), but it's also hard to disagree with. The Goths and Vandals were Romanized to a significant degree before they even came West.

I don't think it's fair to say that Roman culture being European is a "retcon". Sure, for the Greeks, but the Romans were the forebears of virtually all European institutions, and any argument that the society Europe consciously modeled itself upon was somehow not European falls apart.

> By the sword. They would ask a city to surrender and convert to Islam, or they would take it by force and either kill or enslave it's citizens. Doesn't sound very peaceful to me.

This differs from the common behavior of powers at the time in what way?

But it's also incredibly misleading. That's what they did to the Crusader States, centuries later, but the collapse of Byzantine/Persian power, and the absence of any strong power blocs in North Africa (after the exarchate of Carthage was established and the Vandals broken) makes this a null argument. Cities traded hands all the time. Without a field army nearby, or, if the field army was decimated, the city essentially had no choice but to surrender.

Additionally, the umma under the Rashiduns and Ummayads often lived outside the city. The caliphate was happy to simply collect taxes, and have Arab troops live among Arabs (as an external garrison).

> And they were also the most prolific slave traders in all of history. It takes a lot of mental gymnastics to say that the caliphates were any more or less peaceful than any other world empires.

This is incredibly speculative. The Romans are estimated to have had anywhere from 5-8m slaves throughout the Empire, for 400 years. We really have no idea what the scale of slavery was like in most of antiquity, or even late antiquity.

You're conveniently forgetting that chattel slavery as practiced in the Americas was wholly different from slavery in the "Old World", also.

I wasn't the one to assert that the caliphate was "more" or "less" peaceful than any other world empire, and I would not. I asserted that it's was peaceful.

If you're going to pick once that is the "most" peaceful based on duration and territory held, I'd go for China, but it's the kind of "who is the best baseball player ever" argument that goes nowhere.

> If you asked me if Rome was peaceful, I would tell you no. But no one is claiming that Rome is peaceful. Once again, there is nothing peaceful about conquering your neighbors, especially ones that didn't attack you first.

Well, some would claim that Rome was peaceful, in the same way that historians may later claim that the US was peaceful. To be honest, it's virtually impossible to stay peaceful when it's kill or be killed. The Romans always had justifications for their wars (often contrived, but still), but I take the converse position.

> Next you will argue that Russia had the right to attack UkraIne because Kievan Rus attacked the people that lived in the areas that are now Russia centuries ago.

I think you're interpreting this backwards. I'm saying that the Arabs were well-aware of the rapacious appetite for war their immediate neighbors had after watching the Persians duke it out with the Romans (and Byzantines) for centuries, with firsthand experience of serving in their militaries and watching their (Arab) leaders become enriched. It's not that the Arabs themselves didn't war on the peninsula, but...

Imagine that you're someone who's watched repeated proxy wars from foreign powers, and maybe even taken part in them. For this example, let's use the American colonists. You've watched the French and British recruit your friends and neighbors, either by coercion or bribery, to fight and die for someone else. Now, they've worn each other out, and you have a chance to remove their influence once and for all to put a better society in place. To do this, you need to wipe them off the map (the Americans did this regionally, but Canada was so underpopulated and the rest of the Empire so far away that it's effectively equivalent).

Is this just? Is this peaceful, in the end? To some, yes. To the Arabs, probably.

Yes, there were religious motivations, but it's exactly the same kind of "manifest destiny" that spread the American dominion coast-to-coast. Is it externally peaceful? No. Is the end result (internally) more peaceful? Yes.

(discussions about the relative peace of First Nations elsewhere, since we really can't say what the balance of force was like before European intervention due to lack of documentation, but the loss of territory to the Americans and introduction of horses/gunpowder definitely provided conflict).

> I don't know enough detail to comment on it either way. "I'm not arguing that sharia is a modern, progressive system of law." - we are on the same page then. With that, comes the idea that any comments on "peaceful" and "rightfully counter-attacking" would only, possibly apply in the context of the time.

That's the point, really. History must be evaluated in historical context. It's easy for us to look back now and say "of course the caliphate was warlike" or "of course the Romans were warlike", but that's hindsight. To a denizen of southern Gaul living in 200AD, you'd have a hard time arguing that it was anything but peaceful, and that Rome imposing her dominion on a bunch of barbarians was the best thing that ever happened.

> Edit: I know it's against the rules, but I just want to note that I am not the one downvoting you, appreciate a good argument once in a while.

> implying I care about internet karma points

But really, I don't. I come here to the internet for discussion

Potato/potato. Do you consider the Pax Romana to be peaceful? Arguably, if your neighbors are "barbarians" or "infidels", the most peaceful thing you can do is conquer them to put an end to their incessant warring and impose civilization.

Remember that the Arabs (prior to the caliphate) were used as proxy troops/mercenaries by the Persians/Romans for centuries under the guise of the Ghassanids and Lakhmids. This has repercussions.

You can make the argument that the jizya made them second-class citizens who were tolerated, but you cannot make the argument that they were not tolerated, which stands in stark contrast to the various persecutions of other religious groups under Julian the Apostate, assorted Byzantines who decided that Arianism/whatever was heretical, Zoroastrianism's (well, the Sassanid rulers' interpretation of it) treatment of nonbelievers, etc. I'm not arguing that sharia is a modern, progressive system of law. In the context of 650 AD, though, it definitely was.

> Yea, but I haven't been there or responded to anything with "implying implications" for years, so forgive me this indulgence.

My comment is more that:

> foo bar quuz baaz

> foo

Pick one

Is underservedly dimissive and really doesn't serve to advance the conversation. I do it also (mostly on Reddit, I guess), but the statement you were replying to wasn't obviously fallacious. There's a lot of nuance which you can't hammer away with

>implying

Pretty sure this isn't 4chan.

Don't conflate manifest destiny/religious destiny and culture. The caliphate(s) eventually gave up on sieging Constantinople after the utter failure of 717. But before that, they were essentially a collection of tribes which rapidly expanded, and whose opponents fell so quickly they felt they were destined to bring Islam to the entire world, with Constantinople as a prophecied conquest.

This is less than 100 years after the Rashidun caliphate sprang into existence, and the Islamic Golden Age lasted for centuries after that.

Beyond which, you should not assume that they were not peaceful just because they conquered their neighbors. The laws of the caliphate(s) were extraordinarily generous to believers of other religions, and the caliphate was internally peaceful, enforced charity, successful as a gateway for trade between the East and West, and, yes, actively preserved/translated the writings of previous civilizations until ~1100

The Byzantines were as aligned with the "Orient" as Alexander was. They held onto territory in Italy until a full 600 years after the West fell (once Belisarius recaptured it in the 600s). They had active diplomacy with the Holy Roman Empire and other states in the West up until the 4th Crusade, basically.

You've completely glossed over the Renaissance of the empire around 1000 AD (550 years after the West fell) under John Tzimiskes, Basil II, etc. You can blame this on the decline of Abbasid power if you want, but even if the caliphate _technically_ held territory in Syria/Lebanon, there was no question as to military superiority. The Byzantines raided with impunity and got tribute from the local emirs.

Constantinople lost 90% of its population after the plague of Justinian, and a recurring series of outbreaks over the next centuries, plus a loss of manpower after the desperate end of the Sassanian wars under Heraclius (which Heraclius technically won, but both empires were so diminished that they were easy prey for the new caliphate). It rebounded. Never to its maximum, but it was back near 750000 under the Macedonians.

So, the empire was ok until 660, lost territory, rebounded in the 10th century, and was arguably at its best organizationally and culturally until the real decline started during Manzikert.

It lasted 1000 years. Please read something other than Gibbon, or at least listen to The History of Byzantium (which follows on where The History of Rome left off). History is not a static field, and the Byzantines are rapidly becoming rehabilitated as more documents come up.

The point of this is that OpenLDAP, while an ok solution which has stood the test of time, isn't well integrated with anything a systems vendor would want to do with it. Getting it working with Kerberos or anything else to make it a reasonable alternative to AD is 100 miles of duct tape and random LDIFs.

389 doesn't have any of those problems. Yes, you can argue that Red Hat/SuSE should/could have simply contributed to OpenLDAP, but it hasn't seen a major release in a decade, and there was an incredible amount of friction in trying to contribute anything large.

For me, at least, it's not about learning new paradigms. I like different user paradigms.

It's incredibly inconsistent behavior (see my first post). Is there a reason why I can set the notification sounds for 150 different applications to 150 different things, but I _can't_ set the notification/alarm/ringer volume to different levels?

It speaks of problems when the first thing I needed to do on the phone was Google how to find better alarm clock than it ships with.

Is there a reason why the wifi hotspot is hit or miss? I don't know. It's probably a power saving thing somewhere. I don't care, though. When I have it turned on and no device has connected for a while, it should still be visible in a spectrum scanner without toggling it on/off, right? I guess not.

I'm not even gonna get into Touch ID (which is less reliable than the fingerprint scanner on my Nexus 5x, 4 years ago).

The speed of the phone is fine. The form factor is great. I'd be happy if it either behaved this way or that way all the time, instead of having to guess.

I've mostly gotten used to it, but that doesn't mean I think it's a good experience. It means I've learned to work around it, in the same way that I learned to work around issues on Android. I don't want to talk about the ass-backwards behavior of the search/keyboard tray, and how desperately I miss a "back" button. Try hitting the "Search" in Spotify, then deciding that you actually want to go back. It's far too many taps versus 2 on Android, and it's not intuitive.

Subjective opinion: Android (on a "Google Experience" phone) feels more consistent (breadcrumb/menu button almost always available instead of guessing which edge to swipe from, for example). And that's fine. But it's not what iOS is touted to be.

Counterpoint from someone who actually does own an iPhone after being on Android for years (and I only have an iPhone now because I dropped my Pixel 2, and Fi is taking a long time to send an replacement) -- no, it isn't unparalleled.

The long press/longer press mechanism for removing/moving applications is incredibly unintuitive, and there's no reliable mechanism to figure out which apps do and don't support this.

Swathes of bluetooth problems on an iPhone 8 (and previously, an iPhone 7). If you have airpods, this is probably fine, but they're not appropriate for the gym work I do. It's unacceptable to need to turn bluetooth on the phone off/on in order for the phone to actually pipe audio to a connected bluetooth device.

My iPhone 7 overheated while sitting on my desk and bootlooped. Apple's response? "Time to buy an iPhone 8"

The well-known performance degradation on older batteries to force people onto the upgrade treadmill, because the iPhone 7/8 are not fundamentally different from the 5S/6 in any way, and users weren't upgrading fast enough. There's no other explanation for Apple's behavior.

The "back" button hidden in the upper left corner (assuming the application supports it) don't close tabs in either Safari or Chrome. If you're reading Github pull request from your email and press back, the tab stays. Then you open Chrome and there are 50 tabs open for no reason.

Buying Kindle books is a 4 step process because Apple doesn't allow Amazon to sell products because :reasons:

Digging through 5 different alerting frameworks to get IRC messages forwarded which actually notify, since Pushbullet, Prowl, and friends have apparently not worked correctly after some API changes in IO9 or 10.

If you're heavily invested in the Apple ecosystem, all of this is probably fine. But if you're not, it's death by 1000 cuts, and it's not even a little bit of an intuitive or even good user experience.

My honest opinion is that it's Stockholm syndrome. Android has warts. iOS definitely has warts. Neither is perfect. But I'm tired of seeing people trot out how great the user experience on iOS is.

NetworkManager handles the config file management on its own.

Debian appears to require a flag to enable this on its own: https://wiki.debian.org/NetworkManager#Enabling_Interface_Ma...

If it's enabled, networkmanager will parse out the files and present them over dbus, nmcli, etc. Changes with nmcli, gnome-network (which also uses NM), or other tooling will update the config files. The same ones in /etc/network/interfaces.d/

So, hypothetically:

    auto eth0
    iface eth0 inet static
        address 192.168.40.112
        netmask 255.255.255.0
        gateway 192.168.40.1
        dns-nameservers 8.8.8.8

NM/Cockpit will show all of this information. If you change the address to 192.168.40.113, the config file will be updated (but otherwise unchanged), and the address will change on the running interface.

If it's not enabled, Cockpit will not see the interfaces at all.

Yes, cockpit uses hostnamed and timedated. Plus journalctl, which I noted. I'm perfectly aware of how dbus works, and if you think that hostnamed or timedated have 'idiosyncractic' APIs, I'd challenge you to look at the API for glib.

But it uses these because they are readily available over dbus. Not because cockpit has a hard dependency on systemd.

While that functionality wouldn't work, it would be really trivial to write your own using cockpit.spawn() to call `date`... or `hostname ...` instead of hostnamed or timedated. The truth is that hostnamed and timedated are simply better than the CLI tools.

However, I'm sure the Cockpit team would welcome a patch.

More to the point, there is absolutely nothing in Cockpit which is explicitly using systemd APIs outside of dbus, and this would not be hard to work around.

I know it's cool on HN to hate on systemd, but this is dumb. Cockpit already uses bare `hostname`: https://github.com/cockpit-project/cockpit/blob/dbd7f3a8487a...

It would be a 20 line patch to break the systemd "dependency" on hostnamed. This is not a project intrinsically linked to systemd.

Even your hardwired "example" of journalctl is literally calling a process, which could just as easily be "cat /var/log/messages". It's 'hardwired' because systemd is the standard these days, whether you like it or not. However, extending the promise to simply do that if journalctl fails is trivial.

Maybe your idea of 'hard' dependencies and mine are very different. To me, a 'dependency' on, say, Python, means that there are Python calls all over the place which a reliance on specific semantics. That means that stubbing it out for Ruby or Lua or whatever would be hard. It is not "we wrote our application with this in mind, but we could patch it into stubbable modules in 3 minutes".

It was a workshop, but no videos that I'm aware of.

It was essentially "here's how to use React to build a cockpit plugin from the ground up -- it's easy"

I'm a Python/Go backend developer, mostly, but Cockpit is easy enough that even I can write plugins for it. The workshop basically walked through the git tags in https://github.com/evol262/cockpit-boilerplate

cockpit-ovirt has a "Hosted Engine" tab which is an otopi parser. You'd find it to present exactly the same questions/options as "hosted-engine --deploy" in 4.0/4.1, with ansible and otopi deployments and a new UX in 4.2 which isn't a 1:1 representation of the questions asked.

Once Hosted Engine is deployed, the oVirt cockpit plugin can show the complete status of the HE cluster, put nodes into local maintenance, the whole cluster into maintenance, etc.

Cockpit uses hostnamed, networkmanager, and other services for configuration, not 'ip' or 'hostname'.

Everything you can see is persistent.

Again, Cockpit does not explicitly deal with systemd.

Cockpit deals with dbus, and systemd is conveniently available there (hostnamectl, etc). storaged, networkmanager, and other functionality is not dependent on systemd, so it's really just the system journal, changing the hostname, and checking service status which would fail without systemd.

Docker is not required at all either, though it's an option.

'atomic' is a wrapper. Just look at the dockerfile.

Given how much cockpit wants to, y'know, manage the real system, running it in docker is senseless, and there's no reason to have it in the install guide. If you want it to actually manage your host, use the dockerfile.

I'm the maintainer of the oVirt plugin.

The real advantage of it is that it allows installation of hosted engine easily, and a 'single pane' overview of a host (oVirt Node status without using nodectl, etc)

Since Cockpit wants to deal with dbus, the push is for other utilities (postfix, snmpd, etc) to publish relevant information over dbus, rather than teaching Cockpit the format of each and every configuration file on the system.

I wrote the Tuned plugin for Cockpit, and I maintain the oVirt plugin. I gave a talk at Devconf about plugin development, which is extremely easy, but the Cockpit team is small. It's very easy to write plugins for it, but even easier if they expose dbus.

That said, the cockpit API (http://cockpit-project.org/guide/latest/api-base1) makes handling files/processes from client-side Javascript in plugins simple. It's just that you'd need yet another config file parser...

cockpit is not dependent on systemd. They don't ship sysvinit scripts, but there's no hard dependencies on systemd anywhere. I'd expect that the system logging may not be very nice without journald, but the vast majority of the interface runs over dbus or spawns processes on the server.

It _is_ dependent on dbus.

It is: https://hub.docker.com/r/cockpit/ws/

On which UNIX-like does /etc contain executables critical to system function?

My complaint is primarily that there's no mechanism to let you know "hey, there's an update to this" in the same way as apt, yum, and other systems do.

It's not about trusting a 3rd party with the maintenance and security of your production environment as much as it is "Docker should provide a way to let the people handling the maintenance of your production environment to know shit may be happening". Rebuilding from the 'latest' tag is great. If you know you have to rebuild, and that there's an update available.

Well, no. Everything I listed can be applied in virtually the same way to openstack images or AMIs or whatever... except that the intended use case of those includes regularly updating packages, which docker does not.

My primary contention with your post is that docker doesn't provide a package-manager-like way of ifnding out whether or not you're running older images. Everyone has their own homegrown way of doing it.

1. Don't use old shit 2. Docker should provide a way to tell you you're not running the latest tagged image so you stop running old shit 3. Don't use base images whose maintainers can't be bothered to rebuild when security updates hit

> I didn't mean to make it sound like a business strategy (entirely), I mean it more as a natural progression of how people function. If as an engineer you are spending a lot of time working on Openstack, I'm sure you want to see the new advances and features in the product that you've invested so much time and effort into get into the distro ASAP, as long as they are stable

That's not really up to us, though. We still have product managers and project managers and project leaders who decide that Feature XYZ is going into Openstack Zeta, which comes back around to the original issue.

If I'm an engineer spending a lot of time working on Openstack, it's likely that I'm spending all of my time (other than hobby projects and side projects) on Openstack, just like you may be spending it on whatever your mainline product is (if you're a dev).

All devs probably want to see their features hit stable as soon as possible with wide consumption, but Openstack is a good analogue to Fedora, in the sense that things are operating on a schedule. We aren't releasing new versions of Nova/Neutron/whatever whenever we want or whenever we think it's stable or cool. We try to orchestrate that.

Fedora tries to orchestrate projects.