With some exceptions (e.g. LLVM), Apple's engagement on open source has been consumer only. Even then, it's really around their kernel. Most of the rest of Apple's business is facilitated by closed source software. Of course while they need and provide respectable technology, the real driver of their ludicrous levels of success is more about style/marketing.
IBM does open source extensively, but the bulk of their business centers around proprietary closed software. If IBM open sources something, it's because they gave up figuring out how to monetize it and instead use it for reinforcing their image. IBM is actually interesting, despite nearly dropping completely from the mind of most people, they still command a lead over Microsoft revenue wise.
No company permits 'arbitrary' software. Many companies do trust the employees to understand licensing and 'play with' free software. They generally have an education course on how to find licensing terms and to read the license more deeply for signs of 'commercial use clauses' and what GPL means versus BSD and so on and so forth.
IBM doesn't bat an eye when if an employee puts Fedora on a company asset. They have your ass if you put any open source code into any product without legal review, and also if you use a partner's source code and contribute anything open source based on that. So yes, a long standing large company that is very very very careful about software licensing will go along with it.
Not all 'playing with' is for personal gain. Some of it enables advancing your companies agenda/saving costs/etc. I would not use my personal resources for exploring things that would advance my company without much gratification for me on a personal level.
Which won't by them anything.. They throw out their singular primary advantage (backwards compatibily for decades of application) for.... well actually not much of anything. The Linux kernel can do tricks that Windows kernel cannot, but in the scheme of things not something that will boost MS revenue. The BSD kernels are already roughly at the same functional level, so no new function from that area.
It made sense for Apple because they had only their classic OS which was clearly ill-equipped in fundamental ways and it let them skip the investment of doing it from scratch. MS had already spent that money, so they don't get to skip anything.
If MS started doing a linux distro, it probably would do more harm than good. Distrusted by the target market with a value add that would probably amount to making it easier to manage linux *like* windows, but at that point why not just run Windows? I'd personally be more swayed by the ability to muck about with Windows in the same style as linux, but I recognize that would be a bad idea for Windows.
What kills me is that their update check process sucks up over 2 GB of ram every damn day on my laptop. I have never seen any other platform's *updater* do anything remotely so peculiar. When I didn't have Windows forced on me, I respected it more and assumed they had made a solid product that just wasn't my cup of tea. However I have experienced that their products aren't nearly as well done as I thought they would be...
Only hate is from trolls who like to start flamewars
No it really isn't. Yes there are things it brings to the table. Yes there are problems with some startup scripts. No systemd wasn't the only answer and some decisions that systemd cause real difficulties that come along for the ride along with the good. -Binary log files as the primary strategy is not an absolutely necessary thing to acheive the desired end -Service startup should degrade better when access to pid 1 is not possible -Some software lost capability that could be done under SysV that deviates from the limited path set out by systemd (e.g. 'reload' and also services cannot begin startup until fully stopped, which messes with some software that negotiates handing over in-flight transactions).
I think that's the bulk of the things I can lay squarely at the feet of systemd/journald that causes me grief. I would be less bothered and optimistic that constructive feedback would get these issues addressed, but the way systemd is developed does not inspire confidence. There are other offenders that frustrate me in various ways (pulseaudio, network manager, d-bus, dconf), so systemd does get maligned for the same sort of stuff that others get away with.
Android being sluggish is also not about the kernel. Linux kernel can deliver plenty fast.
Windows kernel is solid enough and all, but lacking a significant chunk of functionality that can be found in linux. Some of that is because it's in userspace in Windows, some of it is because Linux has been an R&D platform for academia for decades and thus has capabilities that MS wouldn't touch with a thousand foot pole as it represents work with about 0% chance for it affecting revenue and non-0% chance of it being a maintenance burden.
I meant the costs of users electing not to upgrade (doing security updates for 3-5 code streams) versus the revenue of personal-use upgrade revenue (which might be nearly nothing).
I doubt that the situation will move that way any more than it already has. The question remains what competitive pressure pushes them into making Windows a loss leader? If you say the competitive pressure is more on the phone and/or tablet front, Microsoft is already doing that ('with Bing' for tablets, and their phone platform is free for any partner that cares). On the laptop/desktop, there is zero competitive pressure (OSX and Linux share *combined* is less than MS's 'failure' that is Windows 8). It's a nice thought that platforms that many of us hold dear could be significant enough to influence the behavior of Microsoft in such a dramatic way, but it's merely a fantasy. Android and IOS has made MS change some things, but nothing in the form factors MS currently charge for.
I could see them deciding the costs of users upgrading isn't worth the revenue of charging for upgrades, but when a vendor wants to preload Windows on a desktop or traditional laptop, you bet your ass MS will continue to demand their slice of that pie (Enterprise is a big cash cow, but so to is the revenue from device manufacturers).
The concept of making money by selling an operating system is a 1990's idea. It made Microsoft a lot of money at one time
That 'one time' is basically from their inception to today. MS revenue in the industry is only behind Apple and IBM. Their biggest money makers continue to be Windows and Office. Windows 8.1, generally cited as MS's failure and antiquated approach compared to Apple 'giving away' OSX (including updates with hardware purchase really) has a larger market share than all the other desktop platforms combined, despite those being 'free' and Windows costing money. Their 'failure' is massively more successful than the competition.
I'm stuck using it due to work and get pissed at it so much and really appreciate using a Linux desktop platform more, but I'm not so deluded as to ignore the market realities. MS isn't going to open source windows (in fact it really can't, there's too much third party cross-licensing deals) and it won't even 'give it away' except under confusing situations that ensure their bread and butter revenue source is protected (for the 'life of the product', not clarifying speculation that they are going subscription, pirates get free upgrade, but still not 'genuine', so really nothing changed).
His point being that to the extent that 'Open Source' plays a fundamental role in a large client's It strategy, the classic MS moves aren't going to give them access to those markets. This has more relevance to products like Office, Visual Studio, Azure, and so on and less about Windows itself really.
That said, it's generally less about the freedom and more about preferred software behavior and/or cheaper. Stamping 'open source' on.Net isn't going to change the fortunes much for better or worse for those that don't use it, though it defuses one of the arguments techies might use to sway their CIOs to try out some alternatives.
MS has been doing a good job lately of saying things that are obviously non-committal (or seemingly committal but actually not when someone digs in and notes a complication and MS won't clarify).
This one goes extra far by conflating Linux open source and how it functions and therefore if Windows were open source, then migration from Linux would be a no-brainer. Of course without promising that but getting that into the 'hearts and minds'.
Of course, I have a hard time blaming them for this. The tech media has all but written eulogies for Windows and have painted MS as a company that is only barely relevant by way of Azure and related cloud services. Despite the fact that they earn about twice as much revenue as Google and their biggest money makers are *still* Windows and Office (by revenue and by an even wider margin by profit). However the story that MS is still one of the biggest tech companies and mostly because of the same stuff that made them big 20 years ago isn't such a sexy story. The revenue and margin on traditional Windows and Office are staggering. Traditional Office revenue dwarfs Office 365 and Office 365 is lower margin.
In short, no they won't be ditching their cash cow to compete with the open source vendors with combined revenue that doesn't match Microsoft's only income. There's two tech companies with more revenue than Microsoft, and neither builds the meat of their business on open source (IBM and Apple). Yes they will continue to feed the media confusing rhetoric to help create false impressions to counteract the media's love of inventive explanations and extrapolation. The biggest risk to MS as a business is getting too caught up in their own smokescreen (e.g. Windows 8 Metro UI).
Of course, I'd rather have less Microsoft in my life, but the likely candidates (ChromeOS, IOS and Android) are not what I would consider an improvement. OSX and Linux desktop distributions I find nice enough, but there's no signs of those superseding Windows.
This would be different as it's a somewhat neglected service for the sake of vague parity with Apple.. If Siri or Cortana started making inroads on *Android* devices, Google would take it pretty seriously and would rapidly relegate third-party solutions to obscurity in short order. This isn't like Wave or Reader or Google code, some exploration of a different market to determine viability, this is directly related to their core business of search.
It's free, but you are only allowed to distribute through Steam (meaning Valve gets 30-40% of your revenue). For a game that was going to sell mostly through Steam *anyway*, it means fewer parties picking at your revenue, but if you somehow weren't using Steam, it represents a big jump from UE4's 5% royalty.
Source 2 is 'free'..... so long as you ONLY make your content available through Steam. For a lot of developers, this is just accepted, but some games aren't on Steam.
So let's say you use UE4 and don't sell through steam. They get 5% royalties. Or Unity, where you pay a flat fee for the game engine.
If you use Source 2 for 'free', the only way to sell it is through Steam, which gets *30-40%* royalties. Source 2 isn't free, it's a hook to try to get more lock-in to keep Steam as the premiere distribution platform.
1. TPM costs money. Almost no one uses it. Therefore, it adds cost and almost no one realizes value. 2. Never used reachit, no idea. 3. A significant cost adder without much value. An eMMC might not be *too* much, but it's still significant. It'd probably be cheaper to ship with a distinct USB key, but really having the ability to put a recovery image to arbitrary USB key is more useful and less likely to become a source of servicing headache in and of itself. 4. Another cost adder that's likely to either be ineffective or a source of problems. 'Hardware' network engines are frequently problematic enough in high-end enterprise products. The absolute crap that would be a consumer grade product makes me cringe.
While I agree with the sentiment that this isn't to be considered unlawful or anything, the word censorship does apply. The word censorship means simply that content is reviewed and objectionable portions suppressed/deleted, not that a state institution is doing it or that there is no alternative way of producing that content.
If a private radio station bleeps out something, it's still called censorship. Sometimes it's for FCC guidelines so it's at least related to government in such cases, but different radio stations exercise different disciplines. For example a song that references weed gets bleeped on one local station, but not another in my area.
The meaning of a word is not something that should be politicized...
Whether Lenovo is engaged or not, it seems Microsoft may wish to issue a purging through a Windows defender update. This would probably be the healthiest thing for all around.
Hopefully this will be a lesson to all the vendors about the risks of taking money for shovelware....
While I'm inclined to also be suspicious of the study and fear people getting the wrong idea that it's ok to drive under *any* impairment, I do find one portion of your comment bizarre:
It's disappointing to see my tax money going to support the use of either.
I'm scratching my head at this sentiment over a study that was probably extraordinarily cheap compared to how much tax money goes towards enforcement and incarceration to fight the use of marijuana.
The pain comes in getting developers all to have share-nothing sensibilities throughout the stack such that any particular piece can fail and it proceeds without a hiccup. A developer uses a quick and dirty BDB, hard to make that stand up regardless of what rug gets yanked out from under it. For developers *trying* to get there, the debug and testing rigor required is significantly higher than what they are accustomed to. Keep in mind that not all these applications are targeted to arbitrarily large audiences, some of them target no more than a small business or team in an instance. If designing for big scale a lot of the sensibilities are unavoidable and you better have the talent to get it done regardless, but not everyone is designing for scale.
To unpleasant user experience, many web sites and mobile apps get their brains thoroughly fried in strange ways during sessions, often rooted in some component falling over that wasn't actually prepared for. For a web page this is usually little more than an annoyance, but mobile app developer recommending reinstall over such a glitch is not uncommon.
This is getting a tad off topic though. Disposable system images are nice for cheap IaaS, but a penalty is paid up the stack that sometimes more than makes up for the savings below, and that situation is very highly dependent upon luck of the pool of talent and skill available in the situation.
One of the big shifts that systemd is embracing is towards IaaS/PaaS type services.
While that is a growing use case, the trend will plateau. Making an application stack that intelligently does that is no small feat, leaving a large chunk of the market not able to make the shift. For an example, look at how most new mainframes are used. Brand new software and hardware stack catering to running software pretty much exactly the way it was run 30 years ago. Some places and developers won't change. Besides, a great deal of companies that brag about how awesome their PaaS implementations do not provide a pleasant user experience and/or suck down a *lot* more resource than they need. Even when people *think* they got the hang of these architectures (after non trivial work toward that goal), they still frequently deliver sub-par experiences.
So logs are binary? Just send them on and do with them whatever you want.
The issue is that plain text has the best parser in the world for when things go badly wrong: the human brain. In a binary format, if things go wrong so that parsers lose track, then it's a lost cause. If structured text log is damaged beyond the reach of the utility, a human can still apply knowledge to do some forensics. Add to that the scenario where you don't have said parsers handy in a 'rescue' context.
At least you finally get to see all the logs and won't find information went MIA because the logger was not yet running or could just not get the data in the first place.
And that speaks to my point, I said that systemd might be able to win over detractors. Binary doesn't add value to any of the cases you described. Those are nice features, and if there were *no* downside, then people wouldn't argue as much about relative value. Right now the discussion is 'but we can do these tricks!' and answered with 'but it isn't worth it', not that the features are inherently bad. If the things given up are mitigated, then the 'we can do these tricks!' becomes more persuasive
More and more apps are going to log there
It will *never* be the case for every app. Syslog was never universally supported. Windows has had decades of an analogous unified logging facility, and not even all *microsoft* code uses it to log. A monolithic logging facility has *never* become ubiquitous for all applications on a system. Besides, that was just one example. Another is that systemd emphasizes 'systemd-nspawn' when there is an 'unshare' command that with a *little* scripting can do the same thing. A wrapper around the utility in shell strikes me as a way to get an entirely new system call into the hands of administrators that is more approachable.
Ok, I meant to say 'not all of the criticism is strictly from a luddite perspective', I recognize that some of it is stubborn rejection of change, but that's no reason to point at that aspect of it and say 'see, they have no leg to stand on, *some* of them can't make a coherent argument as to why they are pissed!'
systemd development should be both proud and concerned. Obviously they have provided value as a non-trivial population stands up and defends them for the sake of the value. Obviously they are leaving some users adrift because so many are pissed. And then there are a lot of people on both sides that just love excuses to argue, but there is definitely a significant meaningful core of supporters and detractors.
All the criticism of systemd is not strictly from a luddite perspective. There is a population that appreciates meaningful advances (Wayland, btrfs, even some facets of systemd), but doesn't like some of the compromises systemd has employed to achieve their goals. Getting stuck in a point of time before systemd is not a desirable result, and in fact systemd might be able to win over some detractors if they recognize criticism and make sensible technical solutions to those rather than continuing to say 'oh everyone loves it except some impossible to please luddites'. For example, journald could embrace native text logging with external binary metadata and deliver all the goodies they provide and quell all the (justified) bitching that human readable logging is a second class citizen in their model.
They may not be able to accommodate all the objections (e.g. the amount of complexity they *must* do in pid 1 to have guaranteed comprehensive service management without blindly applying namespace isolation everywhere that would make a system look even weirder/risk breaking some services), but they could come a long way.
The issue for many of us is that things are being implemented that go beyond what systems administrators can follow along without understanding how to be a more robust software developer (and even then, there's some loss of convenience in analyzing things compared to an interpreted language). Systemd design shifts focus on specialized tools that are better at their specific task, but less reusable in similar contexts. If I started with syslog and learned 'tail -f' will let me watch logs, then I have acquired knowledge that can be used the next time I encounter logging output. If I learn 'journalctl -f', then that knowledge does not transfer to the huge number of other applications that do logging. It's a small example of things that in aggregate pose a significant challenge.
An administrator faced with a 'classic' design won't know everything about the system, but can get far with 'set -x', 'find', and 'grep' because the configuration, logging, and much of the 'glue' code is in clear text, and communication between programs usually hits the filesystem in fairly specific ways. Now with things like systemd and dbus, 'invisible' things happen (well, overly generic communication channels and compiled code). When the kernel implements new awesome stuff, it frequently manifests in sysfs, which is nice and discoverable. Advanced functionality that adheres to the 'everything is a file' and generally presents and accepts simple utf-8/ascii data. Not everything in the kernel does that, sometimes it creates obscure devnodes with ioctls instead, but it's a common and good practice in kernel land.
In general, we already have a system that embraces many of the design principles observed in systemd and actually does a decent job of making the concepts work: Windows. Even with a great deal of talented investment over the course of decades, when a Windows system goes off the reservation in certain ways, no one will be able to bring it back because of how complicated the integration of the various components. While certain concepts can be specifically be done better (e.g. journald does better than windows event framework), the emergent behavior of Windows that becomes impossible to overcome by administrators isn't really due to those specific things.
FYI you may want to try xpra (not wayland, but still). It's better than X forwarding, but operates on principles that translate to the Wayland stack if you dig into it.
Besides, I know portions of NCAR use VirtualGL (at least last I was involved). It does some stuff Xpra doesn't and currently only works with an X stack, but again it operates on principles that don't really intrinsically use the X11 network features.
Of course you may simply be referring to the fact that such approaches has not yet evolved in Wayland ecosystem, rather than implying they are hampered by not having an X11 style approach to remote applications.
As you know the Xserver was network transparent, so neither GNOME/KDE has any capabilities to piggyback on
Which really is still not a big deal, because...
As for Weston, I have not tested it, but Weston does include RDP support from what I can tell.
The best seamless remoting implementation for X11 is no longer actually using the X protocol. Xpra does remote X applications using compositing and window management hooks rather than anything involved in the X11 protocol interaction.
Of course it's entirely plausible that specific scenarios could be better done in the toolkit, but I think the scenarios are frankly limited compared to the complexity of making it happen. At the same time real time encode of graphical content is relatively less expensive. Better to have local applications speak network under the covers for the most part with an Xpra like approach to cover the gap better than even X11 does today.
Slashdot Mirror
With some exceptions (e.g. LLVM), Apple's engagement on open source has been consumer only. Even then, it's really around their kernel. Most of the rest of Apple's business is facilitated by closed source software. Of course while they need and provide respectable technology, the real driver of their ludicrous levels of success is more about style/marketing.
IBM does open source extensively, but the bulk of their business centers around proprietary closed software. If IBM open sources something, it's because they gave up figuring out how to monetize it and instead use it for reinforcing their image. IBM is actually interesting, despite nearly dropping completely from the mind of most people, they still command a lead over Microsoft revenue wise.
No company permits 'arbitrary' software. Many companies do trust the employees to understand licensing and 'play with' free software. They generally have an education course on how to find licensing terms and to read the license more deeply for signs of 'commercial use clauses' and what GPL means versus BSD and so on and so forth.
IBM doesn't bat an eye when if an employee puts Fedora on a company asset. They have your ass if you put any open source code into any product without legal review, and also if you use a partner's source code and contribute anything open source based on that. So yes, a long standing large company that is very very very careful about software licensing will go along with it.
Not all 'playing with' is for personal gain. Some of it enables advancing your companies agenda/saving costs/etc. I would not use my personal resources for exploring things that would advance my company without much gratification for me on a personal level.
Which won't by them anything.. They throw out their singular primary advantage (backwards compatibily for decades of application) for.... well actually not much of anything. The Linux kernel can do tricks that Windows kernel cannot, but in the scheme of things not something that will boost MS revenue. The BSD kernels are already roughly at the same functional level, so no new function from that area.
It made sense for Apple because they had only their classic OS which was clearly ill-equipped in fundamental ways and it let them skip the investment of doing it from scratch. MS had already spent that money, so they don't get to skip anything.
If MS started doing a linux distro, it probably would do more harm than good. Distrusted by the target market with a value add that would probably amount to making it easier to manage linux *like* windows, but at that point why not just run Windows? I'd personally be more swayed by the ability to muck about with Windows in the same style as linux, but I recognize that would be a bad idea for Windows.
What kills me is that their update check process sucks up over 2 GB of ram every damn day on my laptop. I have never seen any other platform's *updater* do anything remotely so peculiar. When I didn't have Windows forced on me, I respected it more and assumed they had made a solid product that just wasn't my cup of tea. However I have experienced that their products aren't nearly as well done as I thought they would be...
Only hate is from trolls who like to start flamewars
No it really isn't. Yes there are things it brings to the table. Yes there are problems with some startup scripts. No systemd wasn't the only answer and some decisions that systemd cause real difficulties that come along for the ride along with the good.
-Binary log files as the primary strategy is not an absolutely necessary thing to acheive the desired end
-Service startup should degrade better when access to pid 1 is not possible
-Some software lost capability that could be done under SysV that deviates from the limited path set out by systemd (e.g. 'reload' and also services cannot begin startup until fully stopped, which messes with some software that negotiates handing over in-flight transactions).
I think that's the bulk of the things I can lay squarely at the feet of systemd/journald that causes me grief. I would be less bothered and optimistic that constructive feedback would get these issues addressed, but the way systemd is developed does not inspire confidence. There are other offenders that frustrate me in various ways (pulseaudio, network manager, d-bus, dconf), so systemd does get maligned for the same sort of stuff that others get away with.
Android being sluggish is also not about the kernel. Linux kernel can deliver plenty fast.
Windows kernel is solid enough and all, but lacking a significant chunk of functionality that can be found in linux. Some of that is because it's in userspace in Windows, some of it is because Linux has been an R&D platform for academia for decades and thus has capabilities that MS wouldn't touch with a thousand foot pole as it represents work with about 0% chance for it affecting revenue and non-0% chance of it being a maintenance burden.
I meant the costs of users electing not to upgrade (doing security updates for 3-5 code streams) versus the revenue of personal-use upgrade revenue (which might be nearly nothing).
I doubt that the situation will move that way any more than it already has. The question remains what competitive pressure pushes them into making Windows a loss leader? If you say the competitive pressure is more on the phone and/or tablet front, Microsoft is already doing that ('with Bing' for tablets, and their phone platform is free for any partner that cares). On the laptop/desktop, there is zero competitive pressure (OSX and Linux share *combined* is less than MS's 'failure' that is Windows 8). It's a nice thought that platforms that many of us hold dear could be significant enough to influence the behavior of Microsoft in such a dramatic way, but it's merely a fantasy. Android and IOS has made MS change some things, but nothing in the form factors MS currently charge for.
I could see them deciding the costs of users upgrading isn't worth the revenue of charging for upgrades, but when a vendor wants to preload Windows on a desktop or traditional laptop, you bet your ass MS will continue to demand their slice of that pie (Enterprise is a big cash cow, but so to is the revenue from device manufacturers).
The concept of making money by selling an operating system is a 1990's idea. It made Microsoft a lot of money at one time
That 'one time' is basically from their inception to today. MS revenue in the industry is only behind Apple and IBM. Their biggest money makers continue to be Windows and Office. Windows 8.1, generally cited as MS's failure and antiquated approach compared to Apple 'giving away' OSX (including updates with hardware purchase really) has a larger market share than all the other desktop platforms combined, despite those being 'free' and Windows costing money. Their 'failure' is massively more successful than the competition.
I'm stuck using it due to work and get pissed at it so much and really appreciate using a Linux desktop platform more, but I'm not so deluded as to ignore the market realities. MS isn't going to open source windows (in fact it really can't, there's too much third party cross-licensing deals) and it won't even 'give it away' except under confusing situations that ensure their bread and butter revenue source is protected (for the 'life of the product', not clarifying speculation that they are going subscription, pirates get free upgrade, but still not 'genuine', so really nothing changed).
His point being that to the extent that 'Open Source' plays a fundamental role in a large client's It strategy, the classic MS moves aren't going to give them access to those markets. This has more relevance to products like Office, Visual Studio, Azure, and so on and less about Windows itself really.
That said, it's generally less about the freedom and more about preferred software behavior and/or cheaper. Stamping 'open source' on .Net isn't going to change the fortunes much for better or worse for those that don't use it, though it defuses one of the arguments techies might use to sway their CIOs to try out some alternatives.
MS has been doing a good job lately of saying things that are obviously non-committal (or seemingly committal but actually not when someone digs in and notes a complication and MS won't clarify).
This one goes extra far by conflating Linux open source and how it functions and therefore if Windows were open source, then migration from Linux would be a no-brainer. Of course without promising that but getting that into the 'hearts and minds'.
Of course, I have a hard time blaming them for this. The tech media has all but written eulogies for Windows and have painted MS as a company that is only barely relevant by way of Azure and related cloud services. Despite the fact that they earn about twice as much revenue as Google and their biggest money makers are *still* Windows and Office (by revenue and by an even wider margin by profit). However the story that MS is still one of the biggest tech companies and mostly because of the same stuff that made them big 20 years ago isn't such a sexy story. The revenue and margin on traditional Windows and Office are staggering. Traditional Office revenue dwarfs Office 365 and Office 365 is lower margin.
In short, no they won't be ditching their cash cow to compete with the open source vendors with combined revenue that doesn't match Microsoft's only income. There's two tech companies with more revenue than Microsoft, and neither builds the meat of their business on open source (IBM and Apple). Yes they will continue to feed the media confusing rhetoric to help create false impressions to counteract the media's love of inventive explanations and extrapolation. The biggest risk to MS as a business is getting too caught up in their own smokescreen (e.g. Windows 8 Metro UI).
Of course, I'd rather have less Microsoft in my life, but the likely candidates (ChromeOS, IOS and Android) are not what I would consider an improvement. OSX and Linux desktop distributions I find nice enough, but there's no signs of those superseding Windows.
This would be different as it's a somewhat neglected service for the sake of vague parity with Apple.. If Siri or Cortana started making inroads on *Android* devices, Google would take it pretty seriously and would rapidly relegate third-party solutions to obscurity in short order. This isn't like Wave or Reader or Google code, some exploration of a different market to determine viability, this is directly related to their core business of search.
It's free, but you are only allowed to distribute through Steam (meaning Valve gets 30-40% of your revenue). For a game that was going to sell mostly through Steam *anyway*, it means fewer parties picking at your revenue, but if you somehow weren't using Steam, it represents a big jump from UE4's 5% royalty.
Source 2 is 'free'..... so long as you ONLY make your content available through Steam. For a lot of developers, this is just accepted, but some games aren't on Steam.
So let's say you use UE4 and don't sell through steam. They get 5% royalties. Or Unity, where you pay a flat fee for the game engine.
If you use Source 2 for 'free', the only way to sell it is through Steam, which gets *30-40%* royalties. Source 2 isn't free, it's a hook to try to get more lock-in to keep Steam as the premiere distribution platform.
1. TPM costs money. Almost no one uses it. Therefore, it adds cost and almost no one realizes value.
2. Never used reachit, no idea.
3. A significant cost adder without much value. An eMMC might not be *too* much, but it's still significant. It'd probably be cheaper to ship with a distinct USB key, but really having the ability to put a recovery image to arbitrary USB key is more useful and less likely to become a source of servicing headache in and of itself.
4. Another cost adder that's likely to either be ineffective or a source of problems. 'Hardware' network engines are frequently problematic enough in high-end enterprise products. The absolute crap that would be a consumer grade product makes me cringe.
While I agree with the sentiment that this isn't to be considered unlawful or anything, the word censorship does apply. The word censorship means simply that content is reviewed and objectionable portions suppressed/deleted, not that a state institution is doing it or that there is no alternative way of producing that content.
If a private radio station bleeps out something, it's still called censorship. Sometimes it's for FCC guidelines so it's at least related to government in such cases, but different radio stations exercise different disciplines. For example a song that references weed gets bleeped on one local station, but not another in my area.
The meaning of a word is not something that should be politicized...
Whether Lenovo is engaged or not, it seems Microsoft may wish to issue a purging through a Windows defender update. This would probably be the healthiest thing for all around.
Hopefully this will be a lesson to all the vendors about the risks of taking money for shovelware....
While I'm inclined to also be suspicious of the study and fear people getting the wrong idea that it's ok to drive under *any* impairment, I do find one portion of your comment bizarre:
It's disappointing to see my tax money going to support the use of either.
I'm scratching my head at this sentiment over a study that was probably extraordinarily cheap compared to how much tax money goes towards enforcement and incarceration to fight the use of marijuana.
The pain comes in getting developers all to have share-nothing sensibilities throughout the stack such that any particular piece can fail and it proceeds without a hiccup. A developer uses a quick and dirty BDB, hard to make that stand up regardless of what rug gets yanked out from under it. For developers *trying* to get there, the debug and testing rigor required is significantly higher than what they are accustomed to. Keep in mind that not all these applications are targeted to arbitrarily large audiences, some of them target no more than a small business or team in an instance. If designing for big scale a lot of the sensibilities are unavoidable and you better have the talent to get it done regardless, but not everyone is designing for scale.
To unpleasant user experience, many web sites and mobile apps get their brains thoroughly fried in strange ways during sessions, often rooted in some component falling over that wasn't actually prepared for. For a web page this is usually little more than an annoyance, but mobile app developer recommending reinstall over such a glitch is not uncommon.
This is getting a tad off topic though. Disposable system images are nice for cheap IaaS, but a penalty is paid up the stack that sometimes more than makes up for the savings below, and that situation is very highly dependent upon luck of the pool of talent and skill available in the situation.
One of the big shifts that systemd is embracing is towards IaaS/PaaS type services.
While that is a growing use case, the trend will plateau. Making an application stack that intelligently does that is no small feat, leaving a large chunk of the market not able to make the shift. For an example, look at how most new mainframes are used. Brand new software and hardware stack catering to running software pretty much exactly the way it was run 30 years ago. Some places and developers won't change. Besides, a great deal of companies that brag about how awesome their PaaS implementations do not provide a pleasant user experience and/or suck down a *lot* more resource than they need. Even when people *think* they got the hang of these architectures (after non trivial work toward that goal), they still frequently deliver sub-par experiences.
So logs are binary? Just send them on and do with them whatever you want.
The issue is that plain text has the best parser in the world for when things go badly wrong: the human brain. In a binary format, if things go wrong so that parsers lose track, then it's a lost cause. If structured text log is damaged beyond the reach of the utility, a human can still apply knowledge to do some forensics. Add to that the scenario where you don't have said parsers handy in a 'rescue' context.
At least you finally get to see all the logs and won't find information went MIA because the logger was not yet running or could just not get the data in the first place.
And that speaks to my point, I said that systemd might be able to win over detractors. Binary doesn't add value to any of the cases you described. Those are nice features, and if there were *no* downside, then people wouldn't argue as much about relative value. Right now the discussion is 'but we can do these tricks!' and answered with 'but it isn't worth it', not that the features are inherently bad. If the things given up are mitigated, then the 'we can do these tricks!' becomes more persuasive
More and more apps are going to log there
It will *never* be the case for every app. Syslog was never universally supported. Windows has had decades of an analogous unified logging facility, and not even all *microsoft* code uses it to log. A monolithic logging facility has *never* become ubiquitous for all applications on a system. Besides, that was just one example. Another is that systemd emphasizes 'systemd-nspawn' when there is an 'unshare' command that with a *little* scripting can do the same thing. A wrapper around the utility in shell strikes me as a way to get an entirely new system call into the hands of administrators that is more approachable.
Ok, I meant to say 'not all of the criticism is strictly from a luddite perspective', I recognize that some of it is stubborn rejection of change, but that's no reason to point at that aspect of it and say 'see, they have no leg to stand on, *some* of them can't make a coherent argument as to why they are pissed!'
systemd development should be both proud and concerned. Obviously they have provided value as a non-trivial population stands up and defends them for the sake of the value. Obviously they are leaving some users adrift because so many are pissed. And then there are a lot of people on both sides that just love excuses to argue, but there is definitely a significant meaningful core of supporters and detractors.
All the criticism of systemd is not strictly from a luddite perspective. There is a population that appreciates meaningful advances (Wayland, btrfs, even some facets of systemd), but doesn't like some of the compromises systemd has employed to achieve their goals. Getting stuck in a point of time before systemd is not a desirable result, and in fact systemd might be able to win over some detractors if they recognize criticism and make sensible technical solutions to those rather than continuing to say 'oh everyone loves it except some impossible to please luddites'. For example, journald could embrace native text logging with external binary metadata and deliver all the goodies they provide and quell all the (justified) bitching that human readable logging is a second class citizen in their model.
They may not be able to accommodate all the objections (e.g. the amount of complexity they *must* do in pid 1 to have guaranteed comprehensive service management without blindly applying namespace isolation everywhere that would make a system look even weirder/risk breaking some services), but they could come a long way.
The issue for many of us is that things are being implemented that go beyond what systems administrators can follow along without understanding how to be a more robust software developer (and even then, there's some loss of convenience in analyzing things compared to an interpreted language). Systemd design shifts focus on specialized tools that are better at their specific task, but less reusable in similar contexts. If I started with syslog and learned 'tail -f' will let me watch logs, then I have acquired knowledge that can be used the next time I encounter logging output. If I learn 'journalctl -f', then that knowledge does not transfer to the huge number of other applications that do logging. It's a small example of things that in aggregate pose a significant challenge.
An administrator faced with a 'classic' design won't know everything about the system, but can get far with 'set -x', 'find', and 'grep' because the configuration, logging, and much of the 'glue' code is in clear text, and communication between programs usually hits the filesystem in fairly specific ways. Now with things like systemd and dbus, 'invisible' things happen (well, overly generic communication channels and compiled code). When the kernel implements new awesome stuff, it frequently manifests in sysfs, which is nice and discoverable. Advanced functionality that adheres to the 'everything is a file' and generally presents and accepts simple utf-8/ascii data. Not everything in the kernel does that, sometimes it creates obscure devnodes with ioctls instead, but it's a common and good practice in kernel land.
In general, we already have a system that embraces many of the design principles observed in systemd and actually does a decent job of making the concepts work: Windows. Even with a great deal of talented investment over the course of decades, when a Windows system goes off the reservation in certain ways, no one will be able to bring it back because of how complicated the integration of the various components. While certain concepts can be specifically be done better (e.g. journald does better than windows event framework), the emergent behavior of Windows that becomes impossible to overcome by administrators isn't really due to those specific things.
FYI you may want to try xpra (not wayland, but still). It's better than X forwarding, but operates on principles that translate to the Wayland stack if you dig into it.
Besides, I know portions of NCAR use VirtualGL (at least last I was involved). It does some stuff Xpra doesn't and currently only works with an X stack, but again it operates on principles that don't really intrinsically use the X11 network features.
Of course you may simply be referring to the fact that such approaches has not yet evolved in Wayland ecosystem, rather than implying they are hampered by not having an X11 style approach to remote applications.
As you know the Xserver was network transparent, so neither GNOME/KDE has any capabilities to piggyback on
Which really is still not a big deal, because...
As for Weston, I have not tested it, but Weston does include RDP support from what I can tell.
The best seamless remoting implementation for X11 is no longer actually using the X protocol. Xpra does remote X applications using compositing and window management hooks rather than anything involved in the X11 protocol interaction.
Of course it's entirely plausible that specific scenarios could be better done in the toolkit, but I think the scenarios are frankly limited compared to the complexity of making it happen. At the same time real time encode of graphical content is relatively less expensive. Better to have local applications speak network under the covers for the most part with an Xpra like approach to cover the gap better than even X11 does today.