Banks in my country have very streamlined transactions. For example I can pay about 10 monthly bills (where I don't want debit orders) to pre-configured beneficiaries in under 2 minutes (including logging in with 2FA). Some banks even have dedicated once-off payment support (where one additional authorisation step is required over paying existing beneficiaries, but more streamlined than first adding a beneficiary and then doing a 2nd step to pay).
Other mobey transfer methods (e.g. Paypal) aren't very popular, because using internet or "cellphone" (USSD-based) or smart phone banking features from our 4 or 5 major banks is so easy and safe.
Some retail-focused payment apps (Snapscan) are popular though (replacong cash or card-present transactions).
For transfers to people who don't have bank accounts but have cellphones (probably about 50% of the adult population), most banks here have 'cash send' featured where ftom the internet banking site or USSD or smart phone app you can effectively send cash to a cellphone number. The recipient can go to any bank ATM and withdraw the cash using SMS-or USSD validation.
Sounds like US banking is still in the pre-Web2 era...
"But to make the sound work, AFAIR you had to "manually" install of dozen of old/unsupported x86 libs;"
But this is really a Java problem, and not a Webex problem per se, and problems/work-arounds would heavily depend on which Java run-time your browser launches for WebStart apps and whether you have matching sound plugins installed or not.
Of course, recent Firefox is probably going to break WebStart and all the enterprise-y apps they don't care about but we need. Guess some people will have to dump Firefox to get NPAPI support back.
You give a specific instance where systemd helps you. Just one.
No, I was responding to one of the examples provided as to why 'systemd sucks' in that it seemed (in the past) to hang at boot if there was a bad entry in/etc/fstab. There is good justification for what systemd is doing (and sysvinit doesn't assist the admin at all in this regard, so the sysvinit user is left to modify all sorts of scripts like rc.sysinit - that will be overwritten by a software update - to resolve these problems).
As someone who has also been involved in packaging software for linux distros (and for internal use), I have no problem writing an init script, but I have also seen the many traps that inexperienced users will fall into when writing/modifying an init script. Systemd has done a lot to standardise the way services must behave and provide configuration-based customisation for the most common types of customisation required, such as setting limits, limited configuration required of the service, running a script before starting the daemon etc.
IIRC, you should be able to achieve the same effect in the other scripts by merely checking and waiting on pieces to come up (admittedly, this has been more than a few years, my memory may be hazy as to its simplicity)
I (and you) might be able to, but at present I doubt any of my colleagues would be able to do it correctly without leaving a booby trap for the next sysadmin.
You also specify several workarounds outside of systemd to deal with things others don't like.
So, not using an optional service that systemd provides but doesn't require is a workaround outside of systemd?
The thing you don't address is why systemd, purportedly a startup management system, appears to have taken over as almost a full OS.
So in the past we have run DJBs service tools to supervise processes that are prone to die regularly, but then you can end up with conflicts with what sysvinit wants to do vs what sv_stat, sv etc. want to do, and you have no dependency tracking between the services supervised by the DJBware and the init system (so qmail starts accepting mail before the NFS mailstores are mounted, and bounces the emails until someone notices the alert and mounts the mailstores). Then you have services run by xinetd (started by sysvinit), again with little coordination between them and other services. To me it does make sense to have one daemon that takes care of launching and killing all services. Then again, there is the argument about one cgroup controller (which was apparently the primary reason for systemd in the first place), and as far as I know there isn't a competing init system that has comprehensive built-in native support for cgroups.
It is unfortunate that a lot of other tooling that pre-dates systemd has so much bit-rot that the systemd developers seem to think writing a replacement (e.g. systemd-login) is better than asking the developers (of e.g. ConsoleKit, which itself was a replacement for something, pam_console?) to fix the bugs, but I don't think the intention is to make systemd an OS. And it is quite modular, many of their newer tools are optional (where possible).
Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.... I also can't think why systemd would have any impact on uptime...
5 years? Seriously? You're running on an 5 year old kernel with multiple known issues (TLS, OpenSSL, etc)?
I didn't say they don't get any updates at all. They just don't have kernel updates applied. There are multiple firewalls protecting these specific servers from hostile users/networks, and 90% of the people who have any access at all (e.g. HTTPS access) have sudo rights to run various things as root on them anyway. The only systems that have any firewall access to them are the other monitoring servers, and all the monitoring software is kept up-to-date.
As for systemd, you must not be very well versed in it. SSH Fails,
Yes, some versions of systemd introducing new features may have bugs. Only immature distros would push such versions out to users of stable releases.
Of the 5 major complaints, 3 are about the journal. There are some advantages to it, and some disadvantages, and I think systemd should support not using journald at all, but you can avoid relying on the journal itself by forwarding to syslog and disabling storage.
Regarding giving block devices for filesystems listed as required in/etc/fstab, this is a conscious design decision that is required in environments with complex storage (many storage arrays in a complex storage area network). The alternative (with e.g. sysvinit) is to have your production database servers fail to come up at boot time because the init system didn't give enough time for all 100 LUNs to appear so that it could mount the filesystems required to let the database start. It is really fun to have to be woken up to get such systems back up after a rack has tripped because then engineer on standby can't figure out what to do, I'd rather have systemd do the right thing. As far as I know, the default timeouts have been reduced (systemd wasn't hanging though... it was waiting for devices it was told were required to appear) and provide more information on why it is waiting.
The 4th issue is cosmetic, and applies to most kernel drivers... only dracut namespaces its parameters (rd.xxx).
And that took all of 2 min to search, read, and compile, because I wanted to give you some solid backing for stating it sucks.
Yes, it is trivial to find old bugs that are fixed, and FUD complaints from systemd haters about behaviour that has been improved.
You're in RH land with supported versions, so it's likely that these problems, when they crop up, are offloaded as RH issues and you just monitor a trouble ticket. Lucky you. I guess I wouldn't care in that scenario either, as it's SEP.
Our production servers run Red Hat. We haven't needed to log a ticket for anything systemd-related.
My workstation, my laptop, and the desktop my wife uses at home run a different distro not associated with Red Hat at all that switched to systemd long ago, and I have seen no issues there either.
"Systemd is pants-on-head retarded when dealing with Network Manager and waking from sleep. It/never/ reactivates the network."
In over 3 years running a distro using systemd, I've never seen this problem. All network interfaces work correctly on resume (except the 3G modem that needs its driver reloaded, but this is a driver problem).
"It is also pants-on-head retarded when a sound service won't start and it will just fucking/wait/ there while it won't start, instead of just failing it and moving on."
Never seen this one either. Sound mainly just works, including switching streams to my bluetooth headphones when connected.
"These are issues I've personally had to deal with. With Ubuntu"
Ah, Debian/Ubuntu users complaining about systemd. Why is it the Fedora/SUSE/CentOS/RHEL/Arch/Mageia users don't have these problems? Maybe Debian/Ubuntu-specific issues with their systemd migration/implementation?
" x86/Linux just doesn't cut it. I remember I had a Solaris box in a closet that ran consistently I actually forgot to reboot it for 5 years. The only reason I did wind up rebooting it was because it's memory got upgraded because certain functions got a little slower over time as things grew. Quadrupling memory (memory got both cheaper and larger in the meantime) and boom - back to like it was new. x86 Linux systems, at least pre-systemd, were ok but still require some hand-holding. More than 180 days of uptime wasn't really in the cards. No clue on systemd systems, I won't run one until I have no choice."
What nonsense.
The uptime of our production Linux servers running on Dell PowerEdge, HP ProLiant, Sun "Galaxy" amd/intel servers or now Cisco UCS is limited only by the application of kernel or glibc securuty updates.
Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.
We are migrating (more than 50% done) most workloads to VMs running on Red Hat Enterprise Virtualisation, with 90%+ VMs running RHEL7. Systemd has been a total non-issue. I also can't think why systemd would have any impact on uptime...
"The biggest mistake that happened in the original article was the violation of company policy of registering his own private email address for the administration account. Because of that move, the school (in my opinion) was justified in suing the guy."
I don't know specifically in this case, but in some cases in my position I have access to some work-related features on Google and Facebook linked to my personal accounts. Since our company has no products/services from either, I can't really do anything else except possibly make a dedicated account for that one purpose.
If my manager fires all my colleagues, then me (and forces us out to avoid paying severance), then locks himself out of his account, why should it be my responsibility to help him recover from this situation that he created?
"Hoarding passwords is something that has occurred to all of us, at one time or another. It's such an easy thing to do.
But you can't do that stuff. It's unethical, and immature, and unprofessional."
But, what if you have no other option? What if you weren't actually hoarding, but became the last staff member with rights by attrition, and management didn't show any interest in ensuring administrative continuity (by not filling vacancies etc., or making the effort to see ), even after being informed.
I work for an ISP. Google provides ISPs access to some tools, which require a Google login. Our company doesn't use any Google for business products. Our company doesn't have a policy regarding credentials for 'cloud' services that can't use your company email address. So I used my personal gmail account (like my colleagues and our manager).
Is it my fault if my manager locks himself out after I leave the company, or doesn't bother getting his account linked along with the rest of the team?
I don't think there is a clear-cut case for malicious or negligent behaviour on the side of the employee, but it seems pretty clear that they actively worked him out. In many countries that would have been illegal and he could have sued for unfair dismissal and gotten a year's salary with only a few hour's effort and no significant costs.
But you Americans seem to want to punish any worker who has picked a bad company to work for (what else can explain your lack of basic worker's rights protecting them from vindictive companies such as this one seems to be).
"But outside EV certificates everyone should be using Let's Encrypt certificates. They are trivial to install, secure and renewals can be fully automated. On top of all that they are free. Anyone buying non-EV certificates is neither cost conscious nor values the time of their IT staff."
There are other low-maintenance ways to get certificates, and they don't require you to put all of your trust in one organisation who has no obligations to you.
For all internal uses, we use an internal CA that will automatically renew renewal requests signed by the key of a currently-valid but almost-expiring cert, and an scep client run from cron that will check all certs and enroll for renewals (as well as enroll for the initial cert).
For public certs the certs we renewed before letsencrypt went live are still valid, so for non-security-critical ones we may consider letsencrypt a month or two before those certs expire.
The confusion stems from the fact that a lot of the text comes from a definition of the term gaslighting from the linked blog post:
"Gaslighting occurs at the workplace in the form of bullies unscheduling things youâ(TM)ve scheduled, misplacing files and other items that you are working on and co-workers micro-managing you and being particularly critical of what you do and keeping it under their surveillance. They are watching you too much, implying or blatantly saying that you are doing things wrong when, in fact, you are not. As you can see, this is a competitive maneuver, a way of making you look bad so that they look good;"
So, the only behaviour listed that isn't from the blog post is the supposed over-critical code review.
I can't see that there is any evidence either way between: - the submitter really is competent and the code criticism is unwarranted - this is the submitters first real job and the first real (valid) criticism he has received, and doesn't know how to deal with it
"And you'll have to buy a VM offering like VMware which can help you load balance across your servers, so factor in that cost as well."
What, Hyper-V can't do this yet?
Well, then just run ovirt (on say CentOS or maybe even Ubuntu or Debian), the open-source version of Red Hat Enterprise Virtualisation, which has about the same functionality as vSphere Enterprise (but not quite vSphere Enterprise Plus).
"Where is the evidence for your claim? My experience with my Windows 7 -> Windows 10 upgrade was such that there was a nagware screen from the system tray that afforded me the option to upgrade or not upgrade."
Really, you didn't see all the stories about complaints from users whose Windows 7 devices can't run Windows 10 adequately and got upgraded without ever actively opting in, or in some cases without any notification except being greeted with a Windows 10 login screen, or worse.
Here is an example article of how that dialog you saw changed when Microsoft wasn't satisfied with the slow adoption of Windows 10:
"Anyway, my internet was down until the next morning and even then, it still required a cable modem reset to fix the connection."
Some network equipment vendors sent out field notices about 2 weeks in advance of the leap second, recommending operators to use leap-second smearing (as implemented in chronyd for example) if they had affected versions of network device firmware deployed that could crash as a result.
(We didn't have affected versions deployed, and it would have been non-trivial - at this time of year - to get all our NTP servers upgraded. It't not recommended to use non-smearing and smearing NTP sources on the same device)
"Well, considering there as less than a WEEK between CR's Review and their alleged refusal to Retest, no one should be surprised that Apple hasn't released a patch yet."
All we have to go on at the moment us this statement from TFA:
"In this case, we donâ(TM)t believe re-running the tests are warranted"
We have to assume the use of present tense in this statement has some purpose. Since Apple has (at present) done nothing to address the problem, there is (at present) no justifiable reason to re-test.
Maybe, if Apple finds and fixes the cause, there would be a reason, and then we would have to see what CR says/does. But, they didn't say they would *never* re-test, as you seem to be implying. If you want to maintain that stance, provide a quote that unambiguously supports it.
Otherwise, I don't understand your line of reasoning, as you seem to believe the following: 1) CRs testing methodology is adequate (you haven't contested this) 2) Apple hasn't done anything to address the problem (sure, there hasn't been much time) 3) It is unlikely the outcome will be different (the consequence of (1) and (2)) 4)CR should still repeat the test anyway (maybe "because Apple")? But, that would imply that they are no longer independant.
So, you are either: - incapable of basic logic - a troll - an apple fan-boy
"But what about if Apple just codes to fix the issue, instead?"
Then they should: - push out an update to all affected devices - thank CR for finding the issue - hope CR considers re-testing at their own discretion using the publicly-available update
But, they don't even seem to know what the real cause is yet, and AFAik haven't indicated that they have a fix yet.
"I have a brand new Dell laptop for work, and a brand new Macbook Pro for home."
"Brand-new Macbook Pro" refers to one model in like 4 available configuration all costing over $1200. "Brand-new Dell laptop" refers to about 7 models in 50 configurations costing anywhere from $300.
that must have a version of flash that was newer than the newest version released for Linux
No, it works with Chrome on Linux. At least it worked for me this morning accessing a 5.5 vSphere Web Client.
(I haven't tried firefox with Flash 24, but there are a number of sites I need that needed a newer version of Flash, and in many cases the version shipped with Chrome works).
I have used a Netgear before (ISP-supplied DSL modem), but I always: - Use a non-default subnet on the LAN where user devices reside - Use a generic linux distribution that receives regular updates as the internet gateway (running the PPPoE session, recursive DNS and DHCP etc. from the Linux instance) - Isolate the modem from the user devices (since it is not the gateway) if it isn't required as the AP as well
Of course, this isn't a complete solution nor one that is suitable for most end users, and costs more than using an all-in-one solution, but avoids easy attacks that work against most users.
That is what "3D Secure" does. It allows the bank to implement whatever additional verification they want during the credit card transaction. In early implementations I saw additional passwords, but most banks in my country currently use SMS-based OTPs.
The banks have been enforcing the use of 3D-Secure or threatening to suspend merchants.
"I'm vaguely aware of the other show they mentioned, Top Gear, but other than hearing the name, I'm not familiar with the show....from the context I'm guessing it is a British show?"
Top Gear was produced by the BBC, and the live portions of the show were filmed in the UK, but many segments and a lot of the 'special' episodes were filmed in other countried including the U.S.
In many other countries, Top Gear (prior to the last season where Chris Evans was the main presenter) was the 2nd most popular show, second only to Game of Thrones.
In some countries, the most popular tech news sites have had multiple news stories covering Top Gear (Clarkson being fired, May and Hammond quitting the show due to that, the abysmal failure of the show with Evans as the lead presenter) and The Grand Tour (the announcement by Clarkson that he was working on a new show, the announcement by Amazon, some stories about some of the filming in other countries, a detailed story with lots of photos about the filming in the country in question etc.) over the past year.
I don't think it is really necessary to do a long introduction of both The Grand Tour or Top Gear, if you don't know what Top Gear is, it's as useful to you as reading and article on IPv6 replacing IPv4 when you don't know what IPv4 is, and complaining about the summary not explaining what IPv4 is...
"by Microsoft including Ubuntu inside Windows desktop environments, it allows hundreds of millions of users try Ubuntu without having to wipe their disk, re-partition it, install a hypervisor (parallels, VM Ware, VirtualBox, etc.)"
Doesn't Windows 10 include HyperV? It should have been easier to ship HyperV enabled by default on capable hardware, and it would have been trivial to include a VM template.
"
- an obvious good thing for the Ubuntu ecosystem. It also, in the eyes of millions of users validates Linux as a usable operating system."
As an alternative to cmd.exe.
(As far as I know you can't run mir or X.org or wayland on top of the Linux personality of the Windows 10 kernel, and there are a lot of other limitations.
Microsoft seems to only have done this work to: - run docker containers on Windows server - prevent developers running Mac OS X or Linux if they need to develop server-side apps to.run on Linux - ideally for MS as VMs on Azure or docker containers on Windows server Please show proof of anything they have included which isn't strictly required by these two use cases if you think this is good for Linux, e.g. how a developer can develop and test Linux GUI apps on Windows 10 using this feature alone).
Slashdot Mirror
Haha.
Banks in my country have very streamlined transactions. For example I can pay about 10 monthly bills (where I don't want debit orders) to pre-configured beneficiaries in under 2 minutes (including logging in with 2FA). Some banks even have dedicated once-off payment support (where one additional authorisation step is required over paying existing beneficiaries, but more streamlined than first adding a beneficiary and then doing a 2nd step to pay).
Other mobey transfer methods (e.g. Paypal) aren't very popular, because using internet or "cellphone" (USSD-based) or smart phone banking features from our 4 or 5 major banks is so easy and safe.
Some retail-focused payment apps (Snapscan) are popular though (replacong cash or card-present transactions).
For transfers to people who don't have bank accounts but have cellphones (probably about 50% of the adult population), most banks here have 'cash send' featured where ftom the internet banking site or USSD or smart phone app you can effectively send cash to a cellphone number. The recipient can go to any bank ATM and withdraw the cash using SMS-or USSD validation.
Sounds like US banking is still in the pre-Web2 era ...
"But to make the sound work, AFAIR you had to "manually" install of dozen of old/unsupported x86 libs;"
But this is really a Java problem, and not a Webex problem per se, and problems/work-arounds would heavily depend on which Java run-time your browser launches for WebStart apps and whether you have matching sound plugins installed or not.
Of course, recent Firefox is probably going to break WebStart and all the enterprise-y apps they don't care about but we need. Guess some people will have to dump Firefox to get NPAPI support back.
"Every time a vendor wants to do something like a webex we have to fire up a virtual Windows environment for them to utilise, and that's ridiculous."
Webex runs on Linux. More poorly than on Windows, but it runs and I was able to screen share on one occasion when I tried it.
You give a specific instance where systemd helps you. Just one.
No, I was responding to one of the examples provided as to why 'systemd sucks' in that it seemed (in the past) to hang at boot if there was a bad entry in /etc/fstab. There is good justification for what systemd is doing (and sysvinit doesn't assist the admin at all in this regard, so the sysvinit user is left to modify all sorts of scripts like rc.sysinit - that will be overwritten by a software update - to resolve these problems).
As someone who has also been involved in packaging software for linux distros (and for internal use), I have no problem writing an init script, but I have also seen the many traps that inexperienced users will fall into when writing/modifying an init script. Systemd has done a lot to standardise the way services must behave and provide configuration-based customisation for the most common types of customisation required, such as setting limits, limited configuration required of the service, running a script before starting the daemon etc.
IIRC, you should be able to achieve the same effect in the other scripts by merely checking and waiting on pieces to come up (admittedly, this has been more than a few years, my memory may be hazy as to its simplicity)
I (and you) might be able to, but at present I doubt any of my colleagues would be able to do it correctly without leaving a booby trap for the next sysadmin.
You also specify several workarounds outside of systemd to deal with things others don't like.
So, not using an optional service that systemd provides but doesn't require is a workaround outside of systemd?
The thing you don't address is why systemd, purportedly a startup management system, appears to have taken over as almost a full OS.
So in the past we have run DJBs service tools to supervise processes that are prone to die regularly, but then you can end up with conflicts with what sysvinit wants to do vs what sv_stat, sv etc. want to do, and you have no dependency tracking between the services supervised by the DJBware and the init system (so qmail starts accepting mail before the NFS mailstores are mounted, and bounces the emails until someone notices the alert and mounts the mailstores). Then you have services run by xinetd (started by sysvinit), again with little coordination between them and other services. To me it does make sense to have one daemon that takes care of launching and killing all services. Then again, there is the argument about one cgroup controller (which was apparently the primary reason for systemd in the first place), and as far as I know there isn't a competing init system that has comprehensive built-in native support for cgroups.
It is unfortunate that a lot of other tooling that pre-dates systemd has so much bit-rot that the systemd developers seem to think writing a replacement (e.g. systemd-login) is better than asking the developers (of e.g. ConsoleKit, which itself was a replacement for something, pam_console?) to fix the bugs, but I don't think the intention is to make systemd an OS. And it is quite modular, many of their newer tools are optional (where possible).
Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.... I also can't think why systemd would have any impact on uptime ...
5 years? Seriously? You're running on an 5 year old kernel with multiple known issues (TLS, OpenSSL, etc)?
I didn't say they don't get any updates at all. They just don't have kernel updates applied. There are multiple firewalls protecting these specific servers from hostile users/networks, and 90% of the people who have any access at all (e.g. HTTPS access) have sudo rights to run various things as root on them anyway. The only systems that have any firewall access to them are the other monitoring servers, and all the monitoring software is kept up-to-date.
As for systemd, you must not be very well versed in it. SSH Fails,
Yes, some versions of systemd introducing new features may have bugs. Only immature distros would push such versions out to users of stable releases.
NTP
Using timesyncd isn't mandatory. The distro I use on my laptop doesn't use it, RHEL7.3 doesn't ship it.
magically fixed a service startup issue, no one knows why,
Doesn't seem like anyone could reproduce that on other versions (shipped in stable distros, or current).
and just a general list of why systemd sucks.
Of the 5 major complaints, 3 are about the journal. There are some advantages to it, and some disadvantages, and I think systemd should support not using journald at all, but you can avoid relying on the journal itself by forwarding to syslog and disabling storage.
Regarding giving block devices for filesystems listed as required in /etc/fstab, this is a conscious design decision that is required in environments with complex storage (many storage arrays in a complex storage area network). The alternative (with e.g. sysvinit) is to have your production database servers fail to come up at boot time because the init system didn't give enough time for all 100 LUNs to appear so that it could mount the filesystems required to let the database start. It is really fun to have to be woken up to get such systems back up after a rack has tripped because then engineer on standby can't figure out what to do, I'd rather have systemd do the right thing. As far as I know, the default timeouts have been reduced (systemd wasn't hanging though ... it was waiting for devices it was told were required to appear) and provide more information on why it is waiting.
The 4th issue is cosmetic, and applies to most kernel drivers ... only dracut namespaces its parameters (rd.xxx).
And that took all of 2 min to search, read, and compile, because I wanted to give you some solid backing for stating it sucks.
Yes, it is trivial to find old bugs that are fixed, and FUD complaints from systemd haters about behaviour that has been improved.
You're in RH land with supported versions, so it's likely that these problems, when they crop up, are offloaded as RH issues and you just monitor a trouble ticket. Lucky you. I guess I wouldn't care in that scenario either, as it's SEP.
Our production servers run Red Hat. We haven't needed to log a ticket for anything systemd-related.
My workstation, my laptop, and the desktop my wife uses at home run a different distro not associated with Red Hat at all that switched to systemd long ago, and I have seen no issues there either.
"Systemd is pants-on-head retarded when dealing with Network Manager and waking from sleep. It /never/ reactivates the network."
In over 3 years running a distro using systemd, I've never seen this problem. All network interfaces work correctly on resume (except the 3G modem that needs its driver reloaded, but this is a driver problem).
"It is also pants-on-head retarded when a sound service won't start and it will just fucking /wait/ there while it won't start, instead of just failing it and moving on."
Never seen this one either. Sound mainly just works, including switching streams to my bluetooth headphones when connected.
"These are issues I've personally had to deal with. With Ubuntu"
Ah, Debian/Ubuntu users complaining about systemd. Why is it the Fedora/SUSE/CentOS/RHEL/Arch/Mageia users don't have these problems? Maybe Debian/Ubuntu-specific issues with their systemd migration/implementation?
" x86/Linux just doesn't cut it. I remember I had a Solaris box in a closet that ran consistently I actually forgot to reboot it for 5 years. The only reason I did wind up rebooting it was because it's memory got upgraded because certain functions got a little slower over time as things grew. Quadrupling memory (memory got both cheaper and larger in the meantime) and boom - back to like it was new. x86 Linux systems, at least pre-systemd, were ok but still require some hand-holding. More than 180 days of uptime wasn't really in the cards. No clue on systemd systems, I won't run one until I have no choice."
What nonsense.
The uptime of our production Linux servers running on Dell PowerEdge, HP ProLiant, Sun "Galaxy" amd/intel servers or now Cisco UCS is limited only by the application of kernel or glibc securuty updates.
Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.
We are migrating (more than 50% done) most workloads to VMs running on Red Hat Enterprise Virtualisation, with 90%+ VMs running RHEL7. Systemd has been a total non-issue. I also can't think why systemd would have any impact on uptime ...
"The biggest mistake that happened in the original article was the violation of company policy of registering his own private email address for the administration account. Because of that move, the school (in my opinion) was justified in suing the guy."
I don't know specifically in this case, but in some cases in my position I have access to some work-related features on Google and Facebook linked to my personal accounts. Since our company has no products/services from either, I can't really do anything else except possibly make a dedicated account for that one purpose.
If my manager fires all my colleagues, then me (and forces us out to avoid paying severance), then locks himself out of his account, why should it be my responsibility to help him recover from this situation that he created?
"Hoarding passwords is something that has occurred to all of us, at one time or another. It's such an easy thing to do.
But you can't do that stuff. It's unethical, and immature, and unprofessional."
But, what if you have no other option? What if you weren't actually hoarding, but became the last staff member with rights by attrition, and management didn't show any interest in ensuring administrative continuity (by not filling vacancies etc., or making the effort to see ), even after being informed.
I work for an ISP. Google provides ISPs access to some tools, which require a Google login. Our company doesn't use any Google for business products. Our company doesn't have a policy regarding credentials for 'cloud' services that can't use your company email address. So I used my personal gmail account (like my colleagues and our manager).
Is it my fault if my manager locks himself out after I leave the company, or doesn't bother getting his account linked along with the rest of the team?
I don't think there is a clear-cut case for malicious or negligent behaviour on the side of the employee, but it seems pretty clear that they actively worked him out. In many countries that would have been illegal and he could have sued for unfair dismissal and gotten a year's salary with only a few hour's effort and no significant costs.
But you Americans seem to want to punish any worker who has picked a bad company to work for (what else can explain your lack of basic worker's rights protecting them from vindictive companies such as this one seems to be).
"But outside EV certificates everyone should be using Let's Encrypt certificates. They are trivial to install, secure and renewals can be fully automated. On top of all that they are free. Anyone buying non-EV certificates is neither cost conscious nor values the time of their IT staff."
There are other low-maintenance ways to get certificates, and they don't require you to put all of your trust in one organisation who has no obligations to you.
For all internal uses, we use an internal CA that will automatically renew renewal requests signed by the key of a currently-valid but almost-expiring cert, and an scep client run from cron that will check all certs and enroll for renewals (as well as enroll for the initial cert).
For public certs the certs we renewed before letsencrypt went live are still valid, so for non-security-critical ones we may consider letsencrypt a month or two before those certs expire.
The confusion stems from the fact that a lot of the text comes from a definition of the term gaslighting from the linked blog post:
"Gaslighting occurs at the workplace in the form of bullies unscheduling things youâ(TM)ve scheduled, misplacing files and other items that you are working on and co-workers micro-managing you and being particularly critical of what you do and keeping it under their surveillance. They are watching you too much, implying or blatantly saying that you are doing things wrong when, in fact, you are not. As you can see, this is a competitive maneuver, a way of making you look bad so that they look good;"
So, the only behaviour listed that isn't from the blog post is the supposed over-critical code review.
I can't see that there is any evidence either way between:
- the submitter really is competent and the code criticism is unwarranted
- this is the submitters first real job and the first real (valid) criticism he has received, and doesn't know how to deal with it
"And you'll have to buy a VM offering like VMware which can help you load balance across your servers, so factor in that cost as well."
What, Hyper-V can't do this yet?
Well, then just run ovirt (on say CentOS or maybe even Ubuntu or Debian), the open-source version of Red Hat Enterprise Virtualisation, which has about the same functionality as vSphere Enterprise (but not quite vSphere Enterprise Plus).
"Where is the evidence for your claim? My experience with my Windows 7 -> Windows 10 upgrade was such that there was a nagware screen from the system tray that afforded me the option to upgrade or not upgrade."
Really, you didn't see all the stories about complaints from users whose Windows 7 devices can't run Windows 10 adequately and got upgraded without ever actively opting in, or in some cases without any notification except being greeted with a Windows 10 login screen, or worse.
Here is an example article of how that dialog you saw changed when Microsoft wasn't satisfied with the slow adoption of Windows 10:
http://www.pcworld.com/article...
That was the first links from googling obvious search terms ...
"Anyway, my internet was down until the next morning and even then, it still required a cable modem reset to fix the connection."
Some network equipment vendors sent out field notices about 2 weeks in advance of the leap second, recommending operators to use leap-second smearing (as implemented in chronyd for example) if they had affected versions of network device firmware deployed that could crash as a result.
(We didn't have affected versions deployed, and it would have been non-trivial - at this time of year - to get all our NTP servers upgraded. It't not recommended to use non-smearing and smearing NTP sources on the same device)
"Well, considering there as less than a WEEK between CR's Review and their alleged refusal to Retest, no one should be surprised that Apple hasn't released a patch yet."
All we have to go on at the moment us this statement from TFA:
"In this case, we donâ(TM)t believe re-running the tests are warranted"
We have to assume the use of present tense in this statement has some purpose. Since Apple has (at present) done nothing to address the problem, there is (at present) no justifiable reason to re-test.
Maybe, if Apple finds and fixes the cause, there would be a reason, and then we would have to see what CR says/does. But, they didn't say they would *never* re-test, as you seem to be implying. If you want to maintain that stance, provide a quote that unambiguously supports it.
Otherwise, I don't understand your line of reasoning, as you seem to believe the following:
1) CRs testing methodology is adequate (you haven't contested this)
2) Apple hasn't done anything to address the problem (sure, there hasn't been much time)
3) It is unlikely the outcome will be different (the consequence of (1) and (2))
4)CR should still repeat the test anyway (maybe "because Apple")? But, that would imply that they are no longer independant.
So, you are either:
- incapable of basic logic
- a troll
- an apple fan-boy
"But what about if Apple just codes to fix the issue, instead?"
Then they should:
- push out an update to all affected devices
- thank CR for finding the issue
- hope CR considers re-testing at their own discretion using the publicly-available update
But, they don't even seem to know what the real cause is yet, and AFAik haven't indicated that they have a fix yet.
"I have a brand new Dell laptop for work, and a brand new Macbook Pro for home."
"Brand-new Macbook Pro" refers to one model in like 4 available configuration all costing over $1200. "Brand-new Dell laptop" refers to about 7 models in 50 configurations costing anywhere from $300.
What model Dell was it? A comparable one?
"they should live up to their original offer to "re-test if Apple believes they have found and fixed a problem""
When did Apple issue a software update to fix the problem?
access through a web browser
that must have a version of flash that was newer than the newest version released for Linux
No, it works with Chrome on Linux. At least it worked for me this morning accessing a 5.5 vSphere Web Client.
(I haven't tried firefox with Flash 24, but there are a number of sites I need that needed a newer version of Flash, and in many cases the version shipped with Chrome works).
I have used a Netgear before (ISP-supplied DSL modem), but I always:
- Use a non-default subnet on the LAN where user devices reside
- Use a generic linux distribution that receives regular updates as the internet gateway (running the PPPoE session, recursive DNS and DHCP etc. from the Linux instance)
- Isolate the modem from the user devices (since it is not the gateway) if it isn't required as the AP as well
Of course, this isn't a complete solution nor one that is suitable for most end users, and costs more than using an all-in-one solution, but avoids easy attacks that work against most users.
That is what "3D Secure" does. It allows the bank to implement whatever additional verification they want during the credit card transaction. In early implementations I saw additional passwords, but most banks in my country currently use SMS-based OTPs.
The banks have been enforcing the use of 3D-Secure or threatening to suspend merchants.
As usual, the U.S. is behind most of the world ...
"So your saying MS is Backdooring RHEL."
No, only instances built from the default Azure template.
(And this is one of those problems of 'cloud', you outsource some of your host security in the name of convenience)
Maybe it was a rhetorical question.
"I'm vaguely aware of the other show they mentioned, Top Gear, but other than hearing the name, I'm not familiar with the show....from the context I'm guessing it is a British show?"
Top Gear was produced by the BBC, and the live portions of the show were filmed in the UK, but many segments and a lot of the 'special' episodes were filmed in other countried including the U.S.
In many other countries, Top Gear (prior to the last season where Chris Evans was the main presenter) was the 2nd most popular show, second only to Game of Thrones.
In some countries, the most popular tech news sites have had multiple news stories covering Top Gear (Clarkson being fired, May and Hammond quitting the show due to that, the abysmal failure of the show with Evans as the lead presenter) and The Grand Tour (the announcement by Clarkson that he was working on a new show, the announcement by Amazon, some stories about some of the filming in other countries, a detailed story with lots of photos about the filming in the country in question etc.) over the past year.
I don't think it is really necessary to do a long introduction of both The Grand Tour or Top Gear, if you don't know what Top Gear is, it's as useful to you as reading and article on IPv6 replacing IPv4 when you don't know what IPv4 is, and complaining about the summary not explaining what IPv4 is ...
"by Microsoft including Ubuntu inside Windows desktop environments, it allows hundreds of millions of users try Ubuntu without having to wipe their disk, re-partition it, install a hypervisor (parallels, VM Ware, VirtualBox, etc.)"
Doesn't Windows 10 include HyperV? It should have been easier to ship HyperV enabled by default on capable hardware, and it would have been trivial to include a VM template.
"
- an obvious good thing for the Ubuntu ecosystem. It also, in the eyes of millions of users validates Linux as a usable operating system."
As an alternative to cmd.exe.
(As far as I know you can't run mir or X.org or wayland on top of the Linux personality of the Windows 10 kernel, and there are a lot of other limitations.
Microsoft seems to only have done this work to:
- run docker containers on Windows server
- prevent developers running Mac OS X or Linux if they need to develop server-side apps to.run on Linux - ideally for MS as VMs on Azure or docker containers on Windows server
Please show proof of anything they have included which isn't strictly required by these two use cases if you think this is good for Linux, e.g. how a developer can develop and test Linux GUI apps on Windows 10 using this feature alone).