That was a downright 'friendly' approach. MS could start shipping in a mode that forbids anything but UWP by default, under some claim of improving the security of the platform.
They can (credibly) point to both Apple and Android as examples of platforms that have locked application delivery to their respective platform by default. Yes in Android you can enable sideloading (but you get shown a very 'scary' dialog about how risky it is and you really shouldn't do it), but as an application developer, you really have to let Google distribute it for you or else miss out on the market.
IIRC, recent versions of Windows have a mechanism to make applications *think* they are writing to that applications directory but are instead writing to an overlay layer (VirtualStore).
This should mean a user need not have permission to modify it, but older applications (and only older applications *should* be messing with it, like 15 years old at newest) should be none the wiser.
Steam however acts in many ways like a mid 90s windows application. Providing it's own concepts of user directories and divorcing it from the system separation and producing a very weird thing.
I'm fully aware of the value, but investors gravitate toward the do-nothing companies that sell licenses to people who do real stuff.
Hell, I've even seen a sentiment of 'oh, that's just a hardware company, all the hard work was done by their software partner' in discussions among customers.
Capital expense is considered horrible, everything must be leased/rented. Don't own your buildings, lease them. Don't own servers, rent cloud capacity. Don't make processors, design them.
All the hard work in actually bringing these things to reality is considered by the market to be boring, and attention gravitates toward the 'idea' companies.
The sad things is that businesses by and large *hate* any hardware portion of a business. So they're perfectly happy to have a pure IP company that licenses out to companies that in turn are generally *also* fabless. The more they 'saddle' some other sap with the capital intensive business of building and moving real physical goods, the happier they are.
In my work, we deal with a wide variety (basically a large number of existing projects lead by other groups). So not only language, but style guidelines, processes, everything we adjust continuously to match whatever project we are working on at that moment.
I have been in other positions where you must not use anything but the one true process, language, and style guideline as set forth by the company standards.
In terms of when I *choose* for starting new, it's based on the available skills of the team I can put together. Despite all the 'oh language X is better than language Y', 99% of the time it doesn't really matter. You can do most things in any language, so it's most important to select whatever your team is most comfortable with. Yes, the potential performance and resource utilization may be better in some languages versus others, but most of the time with average teams, design choices will matter far more than runtime/compiler differences.
Just give me a good magnetically mated copper-to-copper dock.
This chase after wireless charging through massively less efficient inductive charging is asinine. People didn't *literally* need it to be wireless, they just wanted something that would self-guide and charge and come off easy without thinking about a cable.
I would love it if Moto Z took their pins on the back and made a 'wireless-like' charging dock.
Also, Point of Sale equipment. Tablets ate a big chunk out of that market.
I'll say that the PC industry is faring better in new sales that Tablets by a *wide* margin, showing that PC market continues to be driven by upgrades, while the tablet market is generally not seeking better, faster, stronger.
We can't seem to decide if we want them to replace all of our devices or only a few of them.
No, 'we' haven't shown any confusion on the matter.
The tablet fills the niche of folks who needed 'good enough' compute power in a no-muss, low weight form factor. Analysts and tech media got caught up in the adoption rate by the large untapped market and assumed such a huge surge in sales *surely* meant it was going to supersede personal computers.
Fast forward to today, tablet sales have flatlined because the 'good enough' market has gotten their devices and there's not much of a drive to upgrade constantly. Phones got a bit of a boost by manipulative service plans 'subsidizing' the cost of a phone every two years, but now that's faltering as carriers move away from that, as people *mostly* weren't upgrading for latest and greatest function, but because they were getting one 'for free' every couple of years and 'hey why not' in that scenario.
Meanwhile PC sales have certainly faltered, but not as severely. That market is still driven to some extent by upgrades, at least moreso than the tablet market.
Note that this is bad news for hardware makers and suggests large investments won't pay off in that space, but it does not mean a software developer should ignore the install base.
Personally, I have a desktop, a 12" windows tablet (lenovo x1 tablet) and a 10" android tablet (yoga tab 3 pro). My desktop is for games that can make use of the high wattage components. My windows tablet is basically general laptop usage, with the option to occasionally rip off the keyboard. My android tablet is the best for reading various media (in part because there is a lack of touch friendly windows applications for reading, in part because the hardware form factor with the smaller screen and the bigger battery oriented in a convient way make it better for holding to read).
Actually, a lot of them still are hackable. The challenge being in WRT54G land, it was *the* definitive hackable router. While several are hackable, it's more confusing and frankly with projects named things like 'openwrt' or 'ddwrt', the very name of the ecosystem is still rooted in that product line. So people who want to load up a custom distro but aren't *that* informed have a hard time knowing what is and isn't and which download to pair with which product.
The problem being that Tesla has been pretty cavalier about pushing this stuff. Contrast with others doing autonomous vehicle work and how extremely *careful* they have been about balancing the convenience and safety in a manner more appropriate to the technology.
Generally, governments have a heavier role in regulating this sort of life and death functionality. Tesla's strategy and attitude is illustrating why it can be a good idea for government to come in and regulate this sort of thing.
Also, all road conditions (very incliment weather) and all drivers (a new driver with a license, drunk folks) and so on and so forth. Also, the autonomous systems will 'give up' at the first sign of a situation they determine may be unmanageable, which a human often does not have the luxury to do.
Any statistic from a PR context is almost certainly not as straightforward as it would seem.
It did not see the truck, as the article said no brake was applied at all.
In the previous story about a Tesla auto-parking right into a trailer, Tesla said that they didn't provide sensor coverage that high. So it seems like it may be the case Tesla is effectively driving blind to anything above hood height.
There's missing detail, but everyone keeps assuming because there's a quote saying the 'driver didn't notice' that there was little notice. The driver was almost certainly not paying any attention and trusting autopilot. In other scenarios, it has been previously reported that tesla sensors have a blind spot that makes them fail to detect anything that would clear the hood of the car. Tractor trailers can take a *long* time to maneuver, and in many cases they may start their maneuver and be unable to complete it before previously unseen cars would collide. Generally this isn't *too* terrible because the human driver sees a big ass tractor trailer and compensates.
Here the human wasn't paying attention (in all likelihood) and Tesla's sensors are blind to obstructions at that height (according to a previous instance where an empty Tesla ran into a parked trailer).
Autopilot still has a far better safety record than human drivers.
The problem with this assessment is it is based on the statistics as interpreted and relayed by Tesla as a PR move. The problem being that it's impossible to know if it is comparing like to like.
For example, the summary misquoted, it's actually 'per 94 million' miles in the US. Also, the general statistic includes all drivers, roads, driving circumstances, and driving conditions. The various autonomous car features tend to disengage at any sign of 'uh oh'. Mostly autopilot is only usable on freeway, meaning it skips most intersections where a lot of fatalities occur. You have overly aggressive drivers contributing to the rate. Autopilot will disengage if it can't determine where the road is, a human driver will keep going in some dangerous conditions.
This one sounds like it was a blind spot in Tesla's sensor system (and has been related to another crash).
I always lamented how for the most part I would have to support two ways of doing it: -The standards based way that works with almost every vendor -The version that would work with Cisco, who would refuse to support the standard and instead push their different, but not any better approach and sometimes worse
Sure, many times Cisco's version came first and they deserve props for that, but they were bad about circling back and implementing the cross-vendor approach.
In my experience, in practice IT is largely about avoiding change at all possible cost. Sure, it can be faster or bigger, but if it is *different*, then it is generally reviled.
Cisco's business is largely based on this principle, and there's no denying that the entire industry is forced to replicate their CLI, like it or not (Juniper has been about the only company to have some measure of success with managed networking *without* impersonating the Cisco CLI). There are some asinine things about the Cisco CLI (that have frankly broken the entire way a lot of admins perceive networking in fundamental ways), but they are by and large just a given now.
I have worked in a position to support a variety of vendors and help customers select devices.
When a switch vendor *does* go their own way, management interface wise, no one will touch them for managed switches. They can comply with all the standards, have all the functionality, and outperform Cisco gear in every metric and undercut by a huge margin, but if their CLI does not look like Cisco's IOS style CLI, customers won't touch them with a thousand foot pole.
Juniper has been the only vendor to at least somewhat get away with a non-cisco like CLI, but even then it's generally a tough initial sale.
On most fronts this is true, though the whole commander in chief facet can be a huge problem. The president may unilaterally do things with the military with grave implications.
This is one reason why I generally am worried less about the president's stance on non-military affairs, because ultimately he doesn't actually have that much authority to do very resh things unilaterally than I am about matters of foreign affairs.
I am not a lawyer but I did google for a few seconds...
It looks like to register a *Trade* Mark, you have to be using it in commerce. Let's encrypt not having any financial anything going on can't say their stuff is in commerce, even if they want to.
Secondly, in "Let's Encrypt", it only had value in the first place if it had taken off. If it hadn't taken off, then there would have been no point in 'defending' the name (also, no one would really want it). It did take off, and as such it is so well known *specifically* in this area that their application should be rejected, as 'common law' recognizes unregistered marks if they are relevant and prominent.
I'm very confused as to where you thought I was saying anything about 'going in guns blazing'. Also, Fedora didn't exist in the 90s.
I'm also unsure how you think every criticism constitutes dumping on systemd without 'proof'. A prominent example is the complaint that journald uses a binary format for logs. This is not some spurious claim without 'proof', it simply is the reality, but people disagree on the cost/benefit facet.
Further complicating matters, while it may have once been intended to leverage Redhat's then-leading position in the linux desktop market to gauge reactions and test, it scared people off (by being unstable and fickle) to the point where the remaining user base is pretty sycophantic toward Red Hat. So instead of a nice representative userbase to gauge reaction in the general linux ecosystem, it's become an echo chamber of praise for the platform.
On the Gnome 3 front, I'll agree that it's probably easier to just go with MATE desktop if you miss Gnome 2 that much. I'm sympathetic, but the fork has been pretty viable, so it's not like there's no recourse.
Similarly for pulseaudio, by and large if it is not well liked, it may be ignored. Also as something relatively 'on the fringe', it's not something I feel like RedHat as an organization particularly cares about. Network Manager is another one in this way *mostly* (non-network manager ways of managing wifi have atrophied).
systemd is a different sort of thing in a couple of ways. One is that given it's role, it is not so simply swapped out at user will. It's one of those core components that is difficult to make selectable (like kernel and glibc). As such a user doesn't have as much individual ability to opt in/out, hence the advanced vitriol, as those who dislike it have relatively little recourse than to whine.
Also, to say that RHAT isn't effectively calling the shots over systemd is slily. Of course they are. It is, at it's core, a part of their strategy. It enables some capabilities they really want for their business in providing orchestration capabilities. The leadership of systemd is within redhat. the leadership of the kernel is outside (though RHAT makes a ton of contributions, they are not the leaders). The leadership role is not some arbitrary detail, it's pretty important, *particularly* in systemd that has such a strong vision of what it wants (contrast with an open source project like openstack that kind of meanders about all over the place).
systemd has caused some headaches and there's frustration because expressing those headaches is meat with mostly useless 'me toos' or dismissive 'you are just trolling'. Not a whole lot of 'well, let's see what we can do to address the specific concerns', but instead calling out such viewpoints as just flat out wrong.
Sure, a lot of it has devolved into inane troll copy/paste posts, but there are legitimate gripes and RedHat is in a key position as the pusher of the technology to be the target of frustration.
It's arbitrary, but top500 measures the largest systems by their ability to execute xhpl. It's not the *most* interconnect sensitive thing in the world, but it would not fare well on a folding@home, world community grid, etc type application.
Slashdot Mirror
That was a downright 'friendly' approach. MS could start shipping in a mode that forbids anything but UWP by default, under some claim of improving the security of the platform.
They can (credibly) point to both Apple and Android as examples of platforms that have locked application delivery to their respective platform by default. Yes in Android you can enable sideloading (but you get shown a very 'scary' dialog about how risky it is and you really shouldn't do it), but as an application developer, you really have to let Google distribute it for you or else miss out on the market.
IIRC, recent versions of Windows have a mechanism to make applications *think* they are writing to that applications directory but are instead writing to an overlay layer (VirtualStore).
This should mean a user need not have permission to modify it, but older applications (and only older applications *should* be messing with it, like 15 years old at newest) should be none the wiser.
Steam however acts in many ways like a mid 90s windows application. Providing it's own concepts of user directories and divorcing it from the system separation and producing a very weird thing.
I'm fully aware of the value, but investors gravitate toward the do-nothing companies that sell licenses to people who do real stuff.
Hell, I've even seen a sentiment of 'oh, that's just a hardware company, all the hard work was done by their software partner' in discussions among customers.
Capital expense is considered horrible, everything must be leased/rented. Don't own your buildings, lease them. Don't own servers, rent cloud capacity. Don't make processors, design them.
All the hard work in actually bringing these things to reality is considered by the market to be boring, and attention gravitates toward the 'idea' companies.
The sad things is that businesses by and large *hate* any hardware portion of a business. So they're perfectly happy to have a pure IP company that licenses out to companies that in turn are generally *also* fabless. The more they 'saddle' some other sap with the capital intensive business of building and moving real physical goods, the happier they are.
In my work, we deal with a wide variety (basically a large number of existing projects lead by other groups). So not only language, but style guidelines, processes, everything we adjust continuously to match whatever project we are working on at that moment.
I have been in other positions where you must not use anything but the one true process, language, and style guideline as set forth by the company standards.
In terms of when I *choose* for starting new, it's based on the available skills of the team I can put together. Despite all the 'oh language X is better than language Y', 99% of the time it doesn't really matter. You can do most things in any language, so it's most important to select whatever your team is most comfortable with. Yes, the potential performance and resource utilization may be better in some languages versus others, but most of the time with average teams, design choices will matter far more than runtime/compiler differences.
Just give me a good magnetically mated copper-to-copper dock.
This chase after wireless charging through massively less efficient inductive charging is asinine. People didn't *literally* need it to be wireless, they just wanted something that would self-guide and charge and come off easy without thinking about a cable.
I would love it if Moto Z took their pins on the back and made a 'wireless-like' charging dock.
Also, Point of Sale equipment. Tablets ate a big chunk out of that market.
I'll say that the PC industry is faring better in new sales that Tablets by a *wide* margin, showing that PC market continues to be driven by upgrades, while the tablet market is generally not seeking better, faster, stronger.
We can't seem to decide if we want them to replace all of our devices or only a few of them.
No, 'we' haven't shown any confusion on the matter.
The tablet fills the niche of folks who needed 'good enough' compute power in a no-muss, low weight form factor. Analysts and tech media got caught up in the adoption rate by the large untapped market and assumed such a huge surge in sales *surely* meant it was going to supersede personal computers.
Fast forward to today, tablet sales have flatlined because the 'good enough' market has gotten their devices and there's not much of a drive to upgrade constantly. Phones got a bit of a boost by manipulative service plans 'subsidizing' the cost of a phone every two years, but now that's faltering as carriers move away from that, as people *mostly* weren't upgrading for latest and greatest function, but because they were getting one 'for free' every couple of years and 'hey why not' in that scenario.
Meanwhile PC sales have certainly faltered, but not as severely. That market is still driven to some extent by upgrades, at least moreso than the tablet market.
Note that this is bad news for hardware makers and suggests large investments won't pay off in that space, but it does not mean a software developer should ignore the install base.
Personally, I have a desktop, a 12" windows tablet (lenovo x1 tablet) and a 10" android tablet (yoga tab 3 pro). My desktop is for games that can make use of the high wattage components. My windows tablet is basically general laptop usage, with the option to occasionally rip off the keyboard. My android tablet is the best for reading various media (in part because there is a lack of touch friendly windows applications for reading, in part because the hardware form factor with the smaller screen and the bigger battery oriented in a convient way make it better for holding to read).
Actually, a lot of them still are hackable. The challenge being in WRT54G land, it was *the* definitive hackable router. While several are hackable, it's more confusing and frankly with projects named things like 'openwrt' or 'ddwrt', the very name of the ecosystem is still rooted in that product line. So people who want to load up a custom distro but aren't *that* informed have a hard time knowing what is and isn't and which download to pair with which product.
The problem being that Tesla has been pretty cavalier about pushing this stuff. Contrast with others doing autonomous vehicle work and how extremely *careful* they have been about balancing the convenience and safety in a manner more appropriate to the technology.
Generally, governments have a heavier role in regulating this sort of life and death functionality. Tesla's strategy and attitude is illustrating why it can be a good idea for government to come in and regulate this sort of thing.
Also, all road conditions (very incliment weather) and all drivers (a new driver with a license, drunk folks) and so on and so forth. Also, the autonomous systems will 'give up' at the first sign of a situation they determine may be unmanageable, which a human often does not have the luxury to do.
Any statistic from a PR context is almost certainly not as straightforward as it would seem.
It did not see the truck, as the article said no brake was applied at all.
In the previous story about a Tesla auto-parking right into a trailer, Tesla said that they didn't provide sensor coverage that high. So it seems like it may be the case Tesla is effectively driving blind to anything above hood height.
There's missing detail, but everyone keeps assuming because there's a quote saying the 'driver didn't notice' that there was little notice. The driver was almost certainly not paying any attention and trusting autopilot. In other scenarios, it has been previously reported that tesla sensors have a blind spot that makes them fail to detect anything that would clear the hood of the car. Tractor trailers can take a *long* time to maneuver, and in many cases they may start their maneuver and be unable to complete it before previously unseen cars would collide. Generally this isn't *too* terrible because the human driver sees a big ass tractor trailer and compensates.
Here the human wasn't paying attention (in all likelihood) and Tesla's sensors are blind to obstructions at that height (according to a previous instance where an empty Tesla ran into a parked trailer).
Autopilot still has a far better safety record than human drivers.
The problem with this assessment is it is based on the statistics as interpreted and relayed by Tesla as a PR move. The problem being that it's impossible to know if it is comparing like to like.
For example, the summary misquoted, it's actually 'per 94 million' miles in the US. Also, the general statistic includes all drivers, roads, driving circumstances, and driving conditions. The various autonomous car features tend to disengage at any sign of 'uh oh'. Mostly autopilot is only usable on freeway, meaning it skips most intersections where a lot of fatalities occur. You have overly aggressive drivers contributing to the rate. Autopilot will disengage if it can't determine where the road is, a human driver will keep going in some dangerous conditions.
This one sounds like it was a blind spot in Tesla's sensor system (and has been related to another crash).
I always lamented how for the most part I would have to support two ways of doing it:
-The standards based way that works with almost every vendor
-The version that would work with Cisco, who would refuse to support the standard and instead push their different, but not any better approach and sometimes worse
Sure, many times Cisco's version came first and they deserve props for that, but they were bad about circling back and implementing the cross-vendor approach.
IT is about managing change
In my experience, in practice IT is largely about avoiding change at all possible cost. Sure, it can be faster or bigger, but if it is *different*, then it is generally reviled.
Cisco's business is largely based on this principle, and there's no denying that the entire industry is forced to replicate their CLI, like it or not (Juniper has been about the only company to have some measure of success with managed networking *without* impersonating the Cisco CLI). There are some asinine things about the Cisco CLI (that have frankly broken the entire way a lot of admins perceive networking in fundamental ways), but they are by and large just a given now.
I have worked in a position to support a variety of vendors and help customers select devices.
When a switch vendor *does* go their own way, management interface wise, no one will touch them for managed switches. They can comply with all the standards, have all the functionality, and outperform Cisco gear in every metric and undercut by a huge margin, but if their CLI does not look like Cisco's IOS style CLI, customers won't touch them with a thousand foot pole.
Juniper has been the only vendor to at least somewhat get away with a non-cisco like CLI, but even then it's generally a tough initial sale.
Frankly both of the possible results give me significant concern.
On most fronts this is true, though the whole commander in chief facet can be a huge problem. The president may unilaterally do things with the military with grave implications.
This is one reason why I generally am worried less about the president's stance on non-military affairs, because ultimately he doesn't actually have that much authority to do very resh things unilaterally than I am about matters of foreign affairs.
I am not a lawyer but I did google for a few seconds...
It looks like to register a *Trade* Mark, you have to be using it in commerce. Let's encrypt not having any financial anything going on can't say their stuff is in commerce, even if they want to.
Secondly, in "Let's Encrypt", it only had value in the first place if it had taken off. If it hadn't taken off, then there would have been no point in 'defending' the name (also, no one would really want it). It did take off, and as such it is so well known *specifically* in this area that their application should be rejected, as 'common law' recognizes unregistered marks if they are relevant and prominent.
I'm very confused as to where you thought I was saying anything about 'going in guns blazing'. Also, Fedora didn't exist in the 90s.
I'm also unsure how you think every criticism constitutes dumping on systemd without 'proof'. A prominent example is the complaint that journald uses a binary format for logs. This is not some spurious claim without 'proof', it simply is the reality, but people disagree on the cost/benefit facet.
Further complicating matters, while it may have once been intended to leverage Redhat's then-leading position in the linux desktop market to gauge reactions and test, it scared people off (by being unstable and fickle) to the point where the remaining user base is pretty sycophantic toward Red Hat. So instead of a nice representative userbase to gauge reaction in the general linux ecosystem, it's become an echo chamber of praise for the platform.
On the Gnome 3 front, I'll agree that it's probably easier to just go with MATE desktop if you miss Gnome 2 that much. I'm sympathetic, but the fork has been pretty viable, so it's not like there's no recourse.
Similarly for pulseaudio, by and large if it is not well liked, it may be ignored. Also as something relatively 'on the fringe', it's not something I feel like RedHat as an organization particularly cares about. Network Manager is another one in this way *mostly* (non-network manager ways of managing wifi have atrophied).
systemd is a different sort of thing in a couple of ways. One is that given it's role, it is not so simply swapped out at user will. It's one of those core components that is difficult to make selectable (like kernel and glibc). As such a user doesn't have as much individual ability to opt in/out, hence the advanced vitriol, as those who dislike it have relatively little recourse than to whine.
Also, to say that RHAT isn't effectively calling the shots over systemd is slily. Of course they are. It is, at it's core, a part of their strategy. It enables some capabilities they really want for their business in providing orchestration capabilities. The leadership of systemd is within redhat. the leadership of the kernel is outside (though RHAT makes a ton of contributions, they are not the leaders). The leadership role is not some arbitrary detail, it's pretty important, *particularly* in systemd that has such a strong vision of what it wants (contrast with an open source project like openstack that kind of meanders about all over the place).
systemd has caused some headaches and there's frustration because expressing those headaches is meat with mostly useless 'me toos' or dismissive 'you are just trolling'. Not a whole lot of 'well, let's see what we can do to address the specific concerns', but instead calling out such viewpoints as just flat out wrong.
Sure, a lot of it has devolved into inane troll copy/paste posts, but there are legitimate gripes and RedHat is in a key position as the pusher of the technology to be the target of frustration.
The things I learn about that I never need to know...
https://www.ntia.doc.gov/files...
It's arbitrary, but top500 measures the largest systems by their ability to execute xhpl. It's not the *most* interconnect sensitive thing in the world, but it would not fare well on a folding@home, world community grid, etc type application.