I don't get privacy anymore because sheep are gullible? Hard no that.
I guess I'm trying to say that you don't get to fabricate lies and troll while retaining your anonymity. Or at least nobody is going to have sympathy when you're exposed.
It's clear in this world of misinformation and "fake news" that proof does nothing. That the only way to get an anonymous agent to stop spreading lies is to lift the veil of anonymity.
If someone wishes to criticize, they can either do so carefully and anonymously with cold hard facts. Or they can express their unsupported opinions openly and publicly. There is no middle ground.
It's Linux and systemd. There are dozen different ways to do the simplest damn thing.
Should I use systemd-networkd? Or NetworkManager? Or netctl? Or ConnMan? Or perhaps do it brute force and run dhcpcd or 'ip addr' (for static setup) in my rc.local?
traceroute isn't even installed by default on many popular distros. I guess it's no longer considered a vital debugging tool.
Just a note. If you don't have DHCP or presumably IPv6 autoconfiguration then you're in a bit of a unusual situation compared to most desktop Linux users. On a server with static IP I'd usually run Debian and I know which text file to edit to change my static IP, netmask, gateway, DNS, etc. (but such config files can be different on every distro)
QA is done differently than "someone testing his code". This is not a true QA.
Without diving too deeply down the no true scotsman fallacy, there are many different and industry accepted ways to approach software testing.
At my company both white box and black box is done methodically. Test plans can be written by specialists known as QA engineers, but developers are also responsible for specifying test plans based on SW architecture, requirements, and any industry standards we are required to meet.
Many shops use QA staff for running ad hoc testing and to do test regressions. Where I work we've automated a significant amount of the regression testing, and can enable or disable individual components of the test.
As I wrote above, the only truly stable kernels that you can rely on are kernels maintained by Red Hat and Google (maybe SUSE a little bit),
You can assert whatever you like. But it's not true.
and RHEL (with its derivatives) is the most successful Linux distro in the commercial world.
Technically AOSP has a larger install base than RHEL. Phrases like "most successful" are ambiguous without indicating what is the measure of success.
That sort of nonsense is hardly unique to the open source world. You can find annoying examples of throwing users under the bus from Apple, glibc project, and more.
But I'd like to note you overlooked my statement about de-centralization. I do regression tests on Linux every single commit as part of my job. As do many other companies. Unfortunately we don't really share our test infrastructure with the open source community, they end up having to make due with what resources they can muster on their own.
Because the Linux way of things is so much better, where binaries from one distro won't run on another because of ever so slightly different versions between libraries or changes to ABI. Shipping binaries for Ubuntu 16.04 and don't expect them to work correctly on 14.04 or 18.04. That is how we end up in situations where teams are locked to a specific version of a specific distro.
When I try to look up the weather for San José I get information for Carmen, Provincia San José. Ok, so I try "weather San Jose, CA", it still finds the city in Costa Rica. So I try using a zip code, "weather 95126". Nope, still Costa Rica. The folks at DuckDuckHack make some painful to watch bugs.
Fuchsia already runs on 3 CPU architectures that I know of. Maybe only one of those is POR, but you can grab their tree and play with it today if you want.
Scaling phones up to tablets then to laptops is the story of Android as well. 10 years ago it was a light-weight OS for small touch displays. It struggled to do things like multiple windows, multiple displays, and keyboards that have been common on Linux desktops (X11). Feels like they're trying to repeat history.
They are constantly reinventing the wheel and doing the same programming over and over again.
Well it is a lot more fun to make stuff from scratch.
I've not had any trouble submitting Android patches. But I also don't have problems with the build system, I always use it from within a chroot. Trying to support the hundred or so distros out there is not worth anyone's time.
A microkernel OS written by a multi-billion company will potentially have more security issues as monolithic and bloated Linux, considering that Linux kernel (except for Google and Red) has no QA and regression testing?
As someone who has worked for a multi-billion dollar company on a microkernel the answer is Yes.
Also it's not strictly true that Linux has no QA and no regression testing, it's just not centralized and the level of testing between kernel components is not standardized. But I get your point.
Yeah, top 50 products with security vulnerabilities [cvedetails.com] Linux kernel alone having the most bugs.
It's been my experience that vulns are not disclosed when there is a company in charge that can pay a bounty. Having personally fixed serious issues in services on QNX and VxWorks I don't think they are immune to security issues. Especially VxWorks. The nice thing about QNX is almost nothing is a kernel vulnerability, but there is a lot of privilege escalation you can do through services and often you often don't need to be in the kernel ring / supervisor mode to have read-write to all of system memory. A bug in a lowly QNX service's driver scatter-gather DMA can be as problematic as any low level Linux kernel bug.
I think Linux is not architecturally bad. But the rate that features and optimizations are added makes it difficult to stay on top of security. Small teams writing services for microkernels tend to also do poorly at security, as they lack the resources, experience, and techniques necessary to implement software that proactively mitigates issues.
There are no practical Linux kernel security concerns that wouldn't also apply to something like Fuchsia. Any complex OS written by a small team will potentially have as many if not more security issues as Linux.
Advantages of the Linux kernel is a lot of eyeballs, mature codebase, reasonably good architectures, very wide hardware support, and known to scale up to very large systems.
Disadvantages of Linux is GPL and dealing with a large community of opinionated people. It can be difficult to get big architectural changes in unless a lot of time is spent convincing the top people on LKML.
Fuchsia is probably a better choice than forking Linux. It's smaller and does less so it will be easier to manage by a small team.
I've never done it for CCFL before. All the panels at my work are LED based. and like I said, it's not hard in my experience to replace them.
I can see that OEMs wouldn't want repairs going on. And if there is no ability for a shop to calibrate color, then it is a waste of time to replace a backlight.
I'm fine with my laptop screen being whatever aspect ratio that my keyboard happens to be. I'd rather have a compact laptop that opens up in an airline seat or on a train than an ultra thin laptop that doesn't fit into a small bag.
Backlights are easy to replace. I wonder if anyone is doing repair shops for that. I often swap them out and do color calibration at work and it's not hard at all.
Slashdot Mirror
I'm not proposing a central authority. That's too easy to abuse. I'm suggesting it is already a social convention and a codified law is unnecessary.
If you want some cliché phrase then, they will be judged by the court of public opinion.
I don't get privacy anymore because sheep are gullible? Hard no that.
I guess I'm trying to say that you don't get to fabricate lies and troll while retaining your anonymity. Or at least nobody is going to have sympathy when you're exposed.
It's clear in this world of misinformation and "fake news" that proof does nothing. That the only way to get an anonymous agent to stop spreading lies is to lift the veil of anonymity.
If someone wishes to criticize, they can either do so carefully and anonymously with cold hard facts. Or they can express their unsupported opinions openly and publicly. There is no middle ground.
It's Linux and systemd. There are dozen different ways to do the simplest damn thing.
Should I use systemd-networkd? Or NetworkManager? Or netctl? Or ConnMan? Or perhaps do it brute force and run dhcpcd or 'ip addr' (for static setup) in my rc.local?
traceroute isn't even installed by default on many popular distros. I guess it's no longer considered a vital debugging tool.
Just a note. If you don't have DHCP or presumably IPv6 autoconfiguration then you're in a bit of a unusual situation compared to most desktop Linux users. On a server with static IP I'd usually run Debian and I know which text file to edit to change my static IP, netmask, gateway, DNS, etc. (but such config files can be different on every distro)
QA is done differently than "someone testing his code". This is not a true QA.
Without diving too deeply down the no true scotsman fallacy, there are many different and industry accepted ways to approach software testing.
At my company both white box and black box is done methodically. Test plans can be written by specialists known as QA engineers, but developers are also responsible for specifying test plans based on SW architecture, requirements, and any industry standards we are required to meet.
Many shops use QA staff for running ad hoc testing and to do test regressions. Where I work we've automated a significant amount of the regression testing, and can enable or disable individual components of the test.
As I wrote above, the only truly stable kernels that you can rely on are kernels maintained by Red Hat and Google (maybe SUSE a little bit),
You can assert whatever you like. But it's not true.
and RHEL (with its derivatives) is the most successful Linux distro in the commercial world.
Technically AOSP has a larger install base than RHEL. Phrases like "most successful" are ambiguous without indicating what is the measure of success.
so you would have to spin around to improve reception? Somehow I don't think reviews will be favorable for phones that have shitty performance
I keep forgetting to bring my cell phone.
Most expensive viking funeral ever.
And I demand that Trump deport me there.
That sort of nonsense is hardly unique to the open source world. You can find annoying examples of throwing users under the bus from Apple, glibc project, and more.
But I'd like to note you overlooked my statement about de-centralization. I do regression tests on Linux every single commit as part of my job. As do many other companies. Unfortunately we don't really share our test infrastructure with the open source community, they end up having to make due with what resources they can muster on their own.
So you are proposing that the best solution is [...]
The only thing I proposed is that it's all shit. So please don't put words in my mouth when I have been clear and concise on my position.
Because the Linux way of things is so much better, where binaries from one distro won't run on another because of ever so slightly different versions between libraries or changes to ABI. Shipping binaries for Ubuntu 16.04 and don't expect them to work correctly on 14.04 or 18.04. That is how we end up in situations where teams are locked to a specific version of a specific distro.
I only hire people who enjoy working 6 days a week and getting paid for 5.
But maybe they search for “duck” in the browser’s address bar expecting it to find DuckDuckGo instead
Those people are computer illiterate.
When I try to look up the weather for San José I get information for Carmen, Provincia San José. Ok, so I try "weather San Jose, CA", it still finds the city in Costa Rica. So I try using a zip code, "weather 95126". Nope, still Costa Rica. The folks at DuckDuckHack make some painful to watch bugs.
I've not seen issues with dust before. Especially for edge lights. But I work in a lab with dust control procedures (sticky mats and air filters)
Fuchsia already runs on 3 CPU architectures that I know of. Maybe only one of those is POR, but you can grab their tree and play with it today if you want.
Scaling phones up to tablets then to laptops is the story of Android as well. 10 years ago it was a light-weight OS for small touch displays. It struggled to do things like multiple windows, multiple displays, and keyboards that have been common on Linux desktops (X11). Feels like they're trying to repeat history.
They are constantly reinventing the wheel and doing the same programming over and over again.
Well it is a lot more fun to make stuff from scratch.
I've not had any trouble submitting Android patches. But I also don't have problems with the build system, I always use it from within a chroot. Trying to support the hundred or so distros out there is not worth anyone's time.
A microkernel OS written by a multi-billion company will potentially have more security issues as monolithic and bloated Linux, considering that Linux kernel (except for Google and Red) has no QA and regression testing?
As someone who has worked for a multi-billion dollar company on a microkernel the answer is Yes.
Also it's not strictly true that Linux has no QA and no regression testing, it's just not centralized and the level of testing between kernel components is not standardized. But I get your point.
Yeah, top 50 products with security vulnerabilities [cvedetails.com] Linux kernel alone having the most bugs.
It's been my experience that vulns are not disclosed when there is a company in charge that can pay a bounty. Having personally fixed serious issues in services on QNX and VxWorks I don't think they are immune to security issues. Especially VxWorks. The nice thing about QNX is almost nothing is a kernel vulnerability, but there is a lot of privilege escalation you can do through services and often you often don't need to be in the kernel ring / supervisor mode to have read-write to all of system memory. A bug in a lowly QNX service's driver scatter-gather DMA can be as problematic as any low level Linux kernel bug.
I think Linux is not architecturally bad. But the rate that features and optimizations are added makes it difficult to stay on top of security. Small teams writing services for microkernels tend to also do poorly at security, as they lack the resources, experience, and techniques necessary to implement software that proactively mitigates issues.
There are no practical Linux kernel security concerns that wouldn't also apply to something like Fuchsia. Any complex OS written by a small team will potentially have as many if not more security issues as Linux.
Advantages of the Linux kernel is a lot of eyeballs, mature codebase, reasonably good architectures, very wide hardware support, and known to scale up to very large systems.
Disadvantages of Linux is GPL and dealing with a large community of opinionated people. It can be difficult to get big architectural changes in unless a lot of time is spent convincing the top people on LKML.
Fuchsia is probably a better choice than forking Linux. It's smaller and does less so it will be easier to manage by a small team.
I've never done it for CCFL before. All the panels at my work are LED based. and like I said, it's not hard in my experience to replace them.
I can see that OEMs wouldn't want repairs going on. And if there is no ability for a shop to calibrate color, then it is a waste of time to replace a backlight.
It only drives forward, and the only user control is a loud horn.
GET OUT OF THE WAY!
I'm fine with my laptop screen being whatever aspect ratio that my keyboard happens to be. I'd rather have a compact laptop that opens up in an airline seat or on a train than an ultra thin laptop that doesn't fit into a small bag.
My Mitsubishi 55" 1080i held up for 14 years.
Backlights are easy to replace. I wonder if anyone is doing repair shops for that. I often swap them out and do color calibration at work and it's not hard at all.