I don't see systemd doing any power management at that level. That would be a 'forward looking statement'.
I agree it is. Right now it is doing the basics:/etc/systemd/logind.conf: HandlePowerKey: specifies which action is invoked when the power key is pressed. HandleSuspendKey: specifies which action is invoked when the suspend key is pressed. HandleHibernateKey: specifies which action is invoked when the hibernate key is pressed. HandleLidSwitch: specifies which action is invoked when the lid is closed.
But more to the point, power management is orthogonal to init.
Sort of. Process need to start and stop around power, that's process management. You really should see systemd as a process manager. Where one of the states it manages is initialization. Thinking of it as init plus some stuff is part of what's hanging you up.
BTW, if the logger can't log to something outside of the node, it is worthless for diagnosing a failure of the node.
Well first off the log is queried if things are going reasonably well. Also it can forward via. a systemd daemon.
I can see some value to a database of logs in some cases. I even wrote a log server that accepts events from syslog-ng and puts them in a database in addition to the text file form. Naturally, it is completely init system agnostic, as a logger should be.
But it shouldn't be process manager independent. Again init is just a small subset of what systemd does.
How so? I can't think of a single instance where any part of GNU/Linux threatened to break something working fine in (for example) Solaris.
It broke their whole ecosystem. It undermined their customer base. For example Linux's GCC pushed out Solaris CC's and more and more software wouldn't compile with CC.
Nobody tried to cram Linux down anyone's throat.
Of course they did. The commercial Unixes are dead. The people who switched away from IRIX, Solaris, Digital Unix... were most certainly forced by having their ecosystem undermined. Only AIX remains and that is fundamentally legacy (excluding NeXTStep which was workstation and became OSX).
GNOME certainly has tried such crap (what a surprise, it's also associated with systemd!). That's why there are now two forks. You might have noticed that there isn't a lot of love for gnome 3.
I'm talking in the GNOME1 days. To pick Ian's own Linux: Progeny Linux Systems which was his distribution was designed to allow for Linux to exist in components based on Gnome. KDE was not an option, Gnome was mandatory. UserLinux was similar.
Fingers out of my pie.
Get a grip. This is open source. There will be distributions that don't support systemd. If there is demand they will exist. There is no force here.
I used to be able to say that. My 2012 rMBP doesn't boot at all with most distributions and when I can get it to boot all sorts of software doesn't work. Mind you this one of the most popular x86 laptops around. But more importantly power management didn't work well ever.
The problem with systemd is that it refuses to be a framework, it wants to be all or nothing.
Yes. Systemd wants to be the plumbing for Linux userspace. Essentially a second kernel offering a large range of services to those distributions that adopt it. So I'd agree it is meant to be all or northing. Which is why there are going to be Linux distributions that likely reject it.
Do you thing gtk could ever have become the popular GUI toolkit that it is if it had a dependency on gimp?
Yes. GTK become popular as part of Gnome and then lots of secondary applications. If GIMP had been tightly integrated into GTK it would have been tightly integrated into Gnome and image manipulation would have been an easy out of the box functionality that all apps had. So for example: screen shot manipulation would have been built into Gnome, likely cut and paste images from video playback built in, word processors would have had sophisticated image controls... Those are the sorts of features that got my wife to use Mac. I'm not seeing the downside.
I don't expect systemd to magically understand a new cgroups API, but I do expect it to get out of the way long enough to develop something that can handle the necessary API change.
That something is going to be systemd. The assumption of systemd is you aren't going to use those features directly. Now obviously if you are going to use them directly you aren't using systemd. Like you said, all or nothing.
They speak of it as if it is fait accompli.
It sorta is. The major distributions have switched. The competitors can't keep up. Obviously things could change but today there is nothing on the horizon I see that's close. Which doesn't mean other things won't be an option but mainstream distributions are going to be systemd.
I only support staying with sysvinit for now. It is currently adequate and won't get in the way of an appropriate framework.
The closest thing to that is OpenRC. The question is whether enough people are going to throw resources at OpenRC to help it keep up. Right now the answer seems to be no. This isn't really an idealogical question it is fundamentally a financial / time one. Will the anti-systemd crowd to the hard work to create the sort of alternative they want? So far I don't see it.
So Google Fiber rates of $70/month for symmetrical 1 Gpbs upload/download speeds are somehow insufficient to run a business as a 'provider'?
Yes. They don't come anywhere near what it costs to move that much bandwidth through the country. Not remotely.
It's clear your a shill for the 'telecommunications providers' here
No, just someone who doesn't live in fantasy land about stuff costs. You can't have a car for $20 and you can't have your own personal 1Gbps fiber running over thousands of miles for $70 / mo.
I gotta wonder, power management worked when sysvinit was on the job
No it didn't. Power management has been a consistent problem with Linux for 2 decades. Even when shutdown and restart work reliably, which is not guaranteed, the best distributions on the best hardware still run for less time due to making poor power choices. Power management is the kind of legacy of failure that is driving people to abandon the initd approach.
The logger isn't supposed to know or care about the status of the system, it's clients know and they send messages about it which the logger logs.
I'm not sure where this "isn't supposed to know" is coming from. You are assuming what you are trying to prove. You are assuming that minimalist logging is the right way to to do things. That's part of what systemd is disagreeing with. In systems with better logging (mainframes, minis, commercial unixes) the logger quite often does know and care about the status of the system. I'd like the option of a more knowledgeable logger.
Note that systemd does not have any node management. It only knows what it is doing on that one machine. There is no cluster management in systemd.
The PaaS takes care of cluster management systemd's job is to manage the low level details of the node. There most certainly is node management. Things like systemd-nspawn are used by GearD, Heat, Atomic (which used GearD)... The newer PaaS which depend on systemd can operate at a higher level of abstraction since systemd takes care of all the single node details. So systemd can create a security context and report status of a container to the PaaS.
BTW the query indexed log of systemd is a another huge advantage for PaaS. It can just ask the node a question and get an intelligent answer back about a specific process it doesn't have to try and parse its way through the entire system log.
But again, uselessd isn't losing functionality, it is moving it to where it belongs (that is, NOT in init).
If uselessd offers the same range of services as systemd then you have a genuine competitor for systemd. If they get there, then there is something to talk about. The pro-systemd argument isn't about architecture it is about functionality. The anti-systemd argument generally pretends this functionality doesn't exist and then based on not understanding why people want the functionality argue against the architecture. The same functionality with a different architecture is a fine compromise. If the uselessd peopel get there, good.
But I don't see the bodies on uselessd. By 4Q2015 you could have a half dozen PaaS with hard systemd dependencies. There is more functionality rolling in all the time. Right now they are trying to make containers even cheaper so that a wider range of applications can experience a custom OS, which means systemd is going to wrap 3rd party libraries and handle runtime dependency resolution for processes. Uselessd guys are going to have to keep up and catch up for lost ground. But if they do, great!
A final point with the political nature, even knowing fully well that external dependencies are a sore point, rather than playing them down, the systemd supporters are talking them up to give the impression there will be an unacceptable amount of breakage if you don't switch to systemd now (switch now or kittend gets it!). That's disgusting.
How is that different than anything else in open source? That's what Linux did to the commercial Unixes. That's what Gnome and KDE both tried to do. Open Source is open source. No one is taking away the ability to run init. What developers are are saying is they are going to do the work to support init. They aren't going to allow init to hold Linux back. There will be distributions that don't use systemd. There will be packages for a long time that don't d
I guess you're not noticing who is propping up all those "ideological politicians"
No I certainly am. But let's not conflate:
a) Politician X has no opinion on Y. Donor Z influences him on Y by donating with b) Politician X has a strong opinion on Y. Donor Z agrees with him on Y and donates.
That's very very different. We've gotten rid of (a) but replacing it with (b).
It was mostly stuff like Tandem and commercial unix running on x86 boxes
SCO was never that big. The Unix running on x86 boxes was Linux. Of course Solaris on Sparc was cheaper as was AIX, NeXT, IRIX... And of course NT as your mention.
. It sure had nothing to do with the workstation market
By 1994-6 absolutely it did. It was the low end Unix option.
FreeBSD was actually both a better choice and more popular in all those roles at the time.
I don't think there was ever a time FreeBSD was more popular. 386BSD was more popular than Linux even earlier than you are talking about.
If end users are all providers then they should be paying the business rate. Right now everyone is under the mistaken belief that a fair systems as an asymmetrical rate where some users who consider themselves providers are being charged far more for the same bandwidth and covering almost 100% of the cost of delivering internet while others are getting tons of bandwidth at the cost of offsetting some-all the cost for the last few miles. So if you want to claim that everyone is a provider then everyone should be paying hundreds to thousands of dollars per month for their bandwidth.
. Until the voter develops the strength to resist the propaganda and simply tune out big money campaigns there is no hope.
The representatives most influenced by money were those in the middle. In 2006, 2008 and 2010 the voters decimated the ranks of politicians who were influenced by big money and replaced them with much more idealogical politicians. In 2014 we are likely to see yet another round of pruning in the Senate. You can like or hate the result but what you are asking for is happening.
You would be a liberal politically or possibly libertarian.
As for USA sillyness regarding risk, I can make pretty similar claims about your countries. For example obsession about dangers of radiation like dangers to food safety from radiation cleaning of meat. Under your theory that this sort of risk poor assessment is unique to USA and Israel how would you explain that?
That is the problem with these "studies". DO NOT look in your backyard for cases that support your bias. Look for cases that contradict your bias. Even if you have to look at the people in other countries. Particularly countries where there is less focus on the items that are controversial in the USofA.
This work is a long tradition of gauging support for rightwing authoritarianism. The earliest forms of the research were done in Italy. It moved to the USA because 70% of all psychology / sociology research is done in the USA.
logind is part of process management. Users initiate process and the system needs to know what to do with them when they for example logoff, hit a powerkey...
It apparently wasn't necessary since it was possible to rip that dependency out (by a third party).
I can rip lots of functionality out of large systems that doesn't mean the functionality was added for political purposes. Those aren't the same thing.
Why isn't journald API compatible with syslog-ng? That would eliminate a lot of objections.
Because systemd knows more the state of the system than the syslogger so the functionality was brought in. Also they were adding functionality (example binary log messages) so to make it compatible they would have had to have written a new version of syslog anyway. Again not political.
Why is udevd being sucked into the repo with systemd?
Because the purpose of udevd is to have the kernel send messages so as to get process responses, that's process management which is a core systemd functionality. That's not scope creep, that's core scope.
Why in the world would PaaS need any of them?
PaaS needs complex process management in each node. So for example if node 56 is having problems keeping process T running which it is supposed to that:
a) It knows b) It can do something useful about it.
Meanwhile, the uselessd project has managed to carve dependencies out left and right. It is not currently a large project.
Well yes. It is stripping functionality away so that systemd / uselessd just boots. Again I'm not arguing that systemd doesn't do more than just replace initd, I'm disagreeing that they added functionality because it was political.
(how important can it be, millions of systems boot fine every day
Well sure. Right now we have external process management. It is being used. Remember Linux has decided to replace big iron Unixes. Which means it is taking over more complex and intricate workloads.
As far as boot fine everyday on desktop they don't boot fine everyday. There are still quite a few problems in getting Linux desktops to "boot right". Decades after doing things like automatically detecting a new CD has been inserted and responding appropriately(code, mp3 music, music CD) is still a messy hack without systemd.
I would rather see a neater more standardized framework for process control and dependency management
What other teams are willing to implement this framework? This gets back to the whole problem that the other init system projects died. If there were multiple init systems then a separate framework between them might make sense. But otherwise systemd's startup files create a framework for the next generation the same way that systemd has to work the basics of init scripts.
Imagine, if I want to mount cgroups with the new unified hierarchy, systemd won't even try to boot the system.
That's true, they are incompatible. Now that cgroups is being rewritten to offer a better framework I'd expect systemd to trail behind implementing those features as options. Systemd can give back some degree of functionality and layer on top of the more modern cgroups framework as it emerges. But right now, yes it is an either / or choice.
There were duplications serviced by 1995 I believe. I tended to buy the commercial releases (RedHat, Mandrake) as the best alternative since they included extra commercial software.
The thing is, the dependencies don't actually make any sense. They only exist because of coding for political purposes.
I haven't seen any evidence for that. Generally the dependencies have been added to serve broader interests usually Free Desktop's or PaaS. I'm sure if you gave a particular dependency I could hunt down the why in under a minute.
You should know that the debate continues in Debian.
I see a small group of people unhappy in Debian. I'm not sure I see a debate. There are two sides. One side is saying "go with the flow" . The other hasn't presented a realistic proposal of what to do about upstream developers creating dependencies other than whine about them. They don't have anywhere near a majority and given they have a much worse argument I don't think they can get one.
If that can't work, then the machine could never have booted in the first place.
Booting it tied to process management in init based systems. Init boots a bunch of different often overlapping and gappy process management solutions like the one you recommended (but larger). systemd replaces them.
OpenRC is kinda dead. Pity I actually like it. But AFACT the authors don't think they can keep up. They weren't able to even port most init scripts into OpenRC and out of init and thus OpenRC was mainly just doing the same stuff.
Yes a device driver. She wanted a transcription foot pedal so she tied various foot pedal actions (think something like a mouse you use with your feet) directly to QuickTime regardless of the currently active application. Totally breaks the paradigm of active application gets input (keyboard, mouse...) that's a custom device driver.
It is inspired by HyperCard, based on the same ideas a successor to it and most importantly the far and away the most successful successor. I don't see anything wrong with considering it the next version of Hypercard. And I'm not alone in that: http://opensource.com/educatio...
LiveCode has pretty good marketing. Their 2013 Kickstarter raised: £493,795. They run smaller ones regularly for one off projects. It wouldn't shock me if LiveCode is in the top 100 most popular languages.
Apple believes that long term legacy is a problem. They want users to migrate paradigms. They don't mind breaking software, to keep the ecosystem clean. Microsoft is far better about continuity. IBM even better than Microsoft.
I have to say the getting people in the door thing is pretty cool. I always like to give this example. My doesn't-know-how-to-program wife wrote herself a custom device driver in AppleTalk without even knowing what a device driver is or what one does. That's success.
Slashdot Mirror
I agree it is. Right now it is doing the basics: /etc/systemd/logind.conf:
HandlePowerKey: specifies which action is invoked when the power key is pressed.
HandleSuspendKey: specifies which action is invoked when the suspend key is pressed.
HandleHibernateKey: specifies which action is invoked when the hibernate key is pressed.
HandleLidSwitch: specifies which action is invoked when the lid is closed.
Sort of. Process need to start and stop around power, that's process management. You really should see systemd as a process manager. Where one of the states it manages is initialization. Thinking of it as init plus some stuff is part of what's hanging you up.
Well first off the log is queried if things are going reasonably well. Also it can forward via. a systemd daemon.
But it shouldn't be process manager independent. Again init is just a small subset of what systemd does.
It broke their whole ecosystem. It undermined their customer base. For example Linux's GCC pushed out Solaris CC's and more and more software wouldn't compile with CC.
Of course they did. The commercial Unixes are dead. The people who switched away from IRIX, Solaris, Digital Unix... were most certainly forced by having their ecosystem undermined. Only AIX remains and that is fundamentally legacy (excluding NeXTStep which was workstation and became OSX).
I'm talking in the GNOME1 days. To pick Ian's own Linux: Progeny Linux Systems which was his distribution was designed to allow for Linux to exist in components based on Gnome. KDE was not an option, Gnome was mandatory. UserLinux was similar.
Get a grip. This is open source. There will be distributions that don't support systemd. If there is demand they will exist. There is no force here.
I used to be able to say that. My 2012 rMBP doesn't boot at all with most distributions and when I can get it to boot all sorts of software doesn't work. Mind you this one of the most popular x86 laptops around. But more importantly power management didn't work well ever.
Yes. Systemd wants to be the plumbing for Linux userspace. Essentially a second kernel offering a large range of services to those distributions that adopt it. So I'd agree it is meant to be all or northing. Which is why there are going to be Linux distributions that likely reject it.
Yes. GTK become popular as part of Gnome and then lots of secondary applications. If GIMP had been tightly integrated into GTK it would have been tightly integrated into Gnome and image manipulation would have been an easy out of the box functionality that all apps had. So for example: screen shot manipulation would have been built into Gnome, likely cut and paste images from video playback built in, word processors would have had sophisticated image controls... Those are the sorts of features that got my wife to use Mac. I'm not seeing the downside.
That something is going to be systemd. The assumption of systemd is you aren't going to use those features directly. Now obviously if you are going to use them directly you aren't using systemd. Like you said, all or nothing.
It sorta is. The major distributions have switched. The competitors can't keep up. Obviously things could change but today there is nothing on the horizon I see that's close. Which doesn't mean other things won't be an option but mainstream distributions are going to be systemd.
The closest thing to that is OpenRC. The question is whether enough people are going to throw resources at OpenRC to help it keep up. Right now the answer seems to be no. This isn't really an idealogical question it is fundamentally a financial / time one. Will the anti-systemd crowd to the hard work to create the sort of alternative they want? So far I don't see it.
Yes. They don't come anywhere near what it costs to move that much bandwidth through the country. Not remotely.
No, just someone who doesn't live in fantasy land about stuff costs. You can't have a car for $20 and you can't have your own personal 1Gbps fiber running over thousands of miles for $70 / mo.
No it didn't. Power management has been a consistent problem with Linux for 2 decades. Even when shutdown and restart work reliably, which is not guaranteed, the best distributions on the best hardware still run for less time due to making poor power choices. Power management is the kind of legacy of failure that is driving people to abandon the initd approach.
I'm not sure where this "isn't supposed to know" is coming from. You are assuming what you are trying to prove. You are assuming that minimalist logging is the right way to to do things. That's part of what systemd is disagreeing with. In systems with better logging (mainframes, minis, commercial unixes) the logger quite often does know and care about the status of the system. I'd like the option of a more knowledgeable logger.
The PaaS takes care of cluster management systemd's job is to manage the low level details of the node. There most certainly is node management. Things like systemd-nspawn are used by GearD, Heat, Atomic (which used GearD)... The newer PaaS which depend on systemd can operate at a higher level of abstraction since systemd takes care of all the single node details. So systemd can create a security context and report status of a container to the PaaS.
BTW the query indexed log of systemd is a another huge advantage for PaaS. It can just ask the node a question and get an intelligent answer back about a specific process it doesn't have to try and parse its way through the entire system log.
If uselessd offers the same range of services as systemd then you have a genuine competitor for systemd. If they get there, then there is something to talk about. The pro-systemd argument isn't about architecture it is about functionality. The anti-systemd argument generally pretends this functionality doesn't exist and then based on not understanding why people want the functionality argue against the architecture. The same functionality with a different architecture is a fine compromise. If the uselessd peopel get there, good.
But I don't see the bodies on uselessd. By 4Q2015 you could have a half dozen PaaS with hard systemd dependencies. There is more functionality rolling in all the time. Right now they are trying to make containers even cheaper so that a wider range of applications can experience a custom OS, which means systemd is going to wrap 3rd party libraries and handle runtime dependency resolution for processes. Uselessd guys are going to have to keep up and catch up for lost ground. But if they do, great!
How is that different than anything else in open source? That's what Linux did to the commercial Unixes. That's what Gnome and KDE both tried to do. Open Source is open source. No one is taking away the ability to run init. What developers are are saying is they are going to do the work to support init. They aren't going to allow init to hold Linux back. There will be distributions that don't use systemd. There will be packages for a long time that don't d
No I certainly am. But let's not conflate:
a) Politician X has no opinion on Y. Donor Z influences him on Y by donating
with
b) Politician X has a strong opinion on Y. Donor Z agrees with him on Y and donates.
That's very very different. We've gotten rid of (a) but replacing it with (b).
SCO was never that big. The Unix running on x86 boxes was Linux. Of course Solaris on Sparc was cheaper as was AIX, NeXT, IRIX... And of course NT as your mention.
By 1994-6 absolutely it did. It was the low end Unix option.
I don't think there was ever a time FreeBSD was more popular. 386BSD was more popular than Linux even earlier than you are talking about.
Exactly! Well said.
If end users are all providers then they should be paying the business rate. Right now everyone is under the mistaken belief that a fair systems as an asymmetrical rate where some users who consider themselves providers are being charged far more for the same bandwidth and covering almost 100% of the cost of delivering internet while others are getting tons of bandwidth at the cost of offsetting some-all the cost for the last few miles. So if you want to claim that everyone is a provider then everyone should be paying hundreds to thousands of dollars per month for their bandwidth.
The representatives most influenced by money were those in the middle. In 2006, 2008 and 2010 the voters decimated the ranks of politicians who were influenced by big money and replaced them with much more idealogical politicians. In 2014 we are likely to see yet another round of pruning in the Senate. You can like or hate the result but what you are asking for is happening.
You would be a liberal politically or possibly libertarian.
As for USA sillyness regarding risk, I can make pretty similar claims about your countries. For example obsession about dangers of radiation like dangers to food safety from radiation cleaning of meat. Under your theory that this sort of risk poor assessment is unique to USA and Israel how would you explain that?
This work is a long tradition of gauging support for rightwing authoritarianism. The earliest forms of the research were done in Italy. It moved to the USA because 70% of all psychology / sociology research is done in the USA.
logind is part of process management. Users initiate process and the system needs to know what to do with them when they for example logoff, hit a powerkey...
I can rip lots of functionality out of large systems that doesn't mean the functionality was added for political purposes. Those aren't the same thing.
Because systemd knows more the state of the system than the syslogger so the functionality was brought in. Also they were adding functionality (example binary log messages) so to make it compatible they would have had to have written a new version of syslog anyway. Again not political.
Because the purpose of udevd is to have the kernel send messages so as to get process responses, that's process management which is a core systemd functionality. That's not scope creep, that's core scope.
PaaS needs complex process management in each node. So for example if node 56 is having problems keeping process T running which it is supposed to that:
a) It knows
b) It can do something useful about it.
Well yes. It is stripping functionality away so that systemd / uselessd just boots. Again I'm not arguing that systemd doesn't do more than just replace initd, I'm disagreeing that they added functionality because it was political.
Well sure. Right now we have external process management. It is being used. Remember Linux has decided to replace big iron Unixes. Which means it is taking over more complex and intricate workloads.
As far as boot fine everyday on desktop they don't boot fine everyday. There are still quite a few problems in getting Linux desktops to "boot right". Decades after doing things like automatically detecting a new CD has been inserted and responding appropriately(code, mp3 music, music CD) is still a messy hack without systemd.
What other teams are willing to implement this framework? This gets back to the whole problem that the other init system projects died. If there were multiple init systems then a separate framework between them might make sense. But otherwise systemd's startup files create a framework for the next generation the same way that systemd has to work the basics of init scripts.
That's true, they are incompatible. Now that cgroups is being rewritten to offer a better framework I'd expect systemd to trail behind implementing those features as options. Systemd can give back some degree of functionality and layer on top of the more modern cgroups framework as it emerges. But right now, yes it is an either / or choice.
You are forgetting Databases (essentially no direct end user interface), CRM, ERP (new interfaces) and UC (phone interface primarily)
True but the ratio is only 2x not 4x on the low end.
There were duplications serviced by 1995 I believe. I tended to buy the commercial releases (RedHat, Mandrake) as the best alternative since they included extra commercial software.
I haven't seen any evidence for that. Generally the dependencies have been added to serve broader interests usually Free Desktop's or PaaS. I'm sure if you gave a particular dependency I could hunt down the why in under a minute.
I see a small group of people unhappy in Debian. I'm not sure I see a debate. There are two sides. One side is saying "go with the flow" . The other hasn't presented a realistic proposal of what to do about upstream developers creating dependencies other than whine about them. They don't have anywhere near a majority and given they have a much worse argument I don't think they can get one.
Booting it tied to process management in init based systems. Init boots a bunch of different often overlapping and gappy process management solutions like the one you recommended (but larger). systemd replaces them.
OpenRC is kinda dead. Pity I actually like it. But AFACT the authors don't think they can keep up. They weren't able to even port most init scripts into OpenRC and out of init and thus OpenRC was mainly just doing the same stuff.
Yes a device driver. She wanted a transcription foot pedal so she tied various foot pedal actions (think something like a mouse you use with your feet) directly to QuickTime regardless of the currently active application. Totally breaks the paradigm of active application gets input (keyboard, mouse...) that's a custom device driver.
It has an executable installer. I'm assuming that's mainly self contained.
It is inspired by HyperCard, based on the same ideas a successor to it and most importantly the far and away the most successful successor. I don't see anything wrong with considering it the next version of Hypercard. And I'm not alone in that: http://opensource.com/educatio...
Excellent link with that hypercard.org
LiveCode has pretty good marketing. Their 2013 Kickstarter raised: £493,795. They run smaller ones regularly for one off projects. It wouldn't shock me if LiveCode is in the top 100 most popular languages.
Apple believes that long term legacy is a problem. They want users to migrate paradigms. They don't mind breaking software, to keep the ecosystem clean. Microsoft is far better about continuity. IBM even better than Microsoft.
You want continuity you picked the wrong product.
I have to say the getting people in the door thing is pretty cool. I always like to give this example. My doesn't-know-how-to-program wife wrote herself a custom device driver in AppleTalk without even knowing what a device driver is or what one does. That's success.
Reading below you wanted greater than / less than. That's obscure syntax. How about
If answer is not "yes" then do X
which is COBOL.