Partisanship, sadly, is going to continue to dominate for the same reason team sports play and people get invested in their 'team' that they really have nothing to do with.
It's much easier to blindly declare some 'team' affiliation to show how much you care and react to the specific candidate when something like a horrible scandal happens. Otherwise you can look engaged without having to be remotely thoughtful.
I use my laptop to connect to datacenter equipment, with a usb serial port and/or an ethernet cable. I use it to connect my phone, generally not at the same time. HDMI I frequently use for conference rooms and presentations.
I currently have a laptop with no ethernet port, and the dongle is such n annoying problem that I will absolutely have a built in ethernet port. An associate has a macbook and in meetings never is the one to present, because the conference rooms never has usb-c and he never has the right dongle with him.
For me, I like the concept of USB-c connector for keyboard/mouse/displayport/ and charge in one port, but I would additionally want at least one USB-a connector, HDMI, and Ethernet jack Maybe in a few years HDMI will get replaced by USB-c (once upon a time, I *needed* VGA, no more), maybe accessories will move to type-c (the more complex and expensive 24 pin usb-c connector adds non-trivial cost to little usb accessories though) but even then I'd want at least two ports. RJ-45 however is going to be with us for the foreseeable future (the cable and connector are just too dirt cheap)
Originally, it was about "you want a super sleek laptop, compromises ok".
Then it lost all meaning as the mainstream went that thin, including apple's own line.
Now taking it at face value, looks like the new meaning will be "ok, fine, we'll play in the budget space". Note their mentioning boosting units sold, this is presumably to try to up their share of the market.
Apple may be buying into what seems to be the general perception in the market: PC market is not going to irrelevance, the relationship between tablet/laptop/phone has somewhat stabilized and PC market turns out to be more lively than tablet.
Does it really sell that well in corporate? I mean apart from one notable anti-microsoft company, I've always seen corps stick to the market where they can make Dell and HP and Lenovo go into a bid war and they don't give a crap about brand value.
Now maybe this upcoming Macbook Air will be cheap and marks Apple actually giving a damn about their share on the busniess PC, but so far they've not acted that way.
I don't think it's that special. It's just that when someone does get sick, it's pretty quick and very pronounced. I don't think I've ever seen a 'percentage' study, mostly anecdotes. As such anecdotes where people feel like they are going to throw up are for more potent than anecdotes where nothing happened.
My wife gets sick just seeing content on the tv that spins around and such, but she can do VR without issue... so long as movement is 1:1.
Of course she doesn't really *care* to, but her disinterest is not due to physical reaction.
That is not a problem for everyone and is even unheard of for certain sorts of experiences (experiences with 0 in-game movement that isn't 1:1 don't make people sick, games with cockpits don't make many people sick, a free-movement fps can make a lot of people sick, but there are a lot of people not in that boat. For example there has not been a VR experience *yet* that perturbed me in the least.
However, current tech is limited and flawed (resolution, optics, weight). It does demand a fair amount of space to participate in. I can be a problem socially where the more blatant isolation is seen as offensive. There are reasons why VR may not take off, but I don't think the sickness is a fatal problem for the industry.
My point is that Apple is of sufficient scale that they already have international distributed data centers. Given they already feel the need to have such a footprint, the incremental cost to do it in-house versus outsourcing for most companies in that position would be lesser than renting the capacity.
I do know of a couple of companies that look at the cost and kick themselves, seeing that their up front decision to cloud host ended up being more costly than in-house, but so would be the cost of migrating, so they are stuck paying higher amounts on an ongoing basis.
Apple has a quarterly profit that exceeds most companies annual revenue at this point, so they have the cash flow to overcome such hurdles, unless their internal IT is just hopeless, they should be able to do a lot to seek the lowest overall cost. By the same token, Apple is on such unbelievably solid ground that they don't need to go by the 'assets are a bigger liability than expense, even if having to spend more money' philosophy that other companies are often stuck with.
They do, however, buy third party servers for their infrastructure, including parts of iCloud hosting.
I would have also expected Apple to have more in-house cloud hosting, as *generally* when you get to very large scale, it becomes cheaper to own it rather than to rent it in absolute terms. From a capital expense versus operational expense, there is still a set of companies that are very averse to having capital, but Apple doesn't strike me as being in a position where they should have to fret about having too much capital.
I can't quite dig up *that*, but there is some content around the same time period talking about '144 mbit' versus the 300 mbit theoretical max, so it seemed that about the same time in development, they were saying 'about half'.
Now this is saying the about half was too optimistic, and instead 1/6th turned out to be the case. If the same carries over to this, then we would still be talking about 150 mbps. In other words, what was hyped for LTE 'real-world' may be the '5G' real-world.
Of course, this *could* be a more realistic simulation and maybe there is a lot of headroom, but historically speaking that's never been the case.
Even Obama himself has expressed the thought that it didn't make a lot of sense. He basically got a prize for the combination of not being George W. Bush and for being first black US president, with some rationalization around him being aligned the right way for a Nobel Peace prize. It's not to say his efforts weren't in the right direction, but there were probably more deserving candidates.
I will concur that this is a whole new level of wrongness. Even if you were of the mindset that he did 'save the internet' (which I find to be absurd), it seems out of place for the NRA to be in the place of awarding a gun based on that, as it doesn't really align with any of NRA's agenda.
I would figure by now there could be libraries of many functions, with a build tool to strip out disused functions as part of minification. Even if things stayed as poor as the code seeing distinct files, would think there would be curated collections of these things rather than a free-for-all repository, where authors can update, add, replace, and remove as they like.
Of course, one would have also hoped the language to get more standard library functionality, having a richer environment built into the browsers rather than having to read big runtimes from the internet all the time.
Maybe the mindset of the loudest contingent of the JS community is just not suited to maintainable ecosystem, but at least there do exist those careful about this sort of thing. Unfortunately it seems the ecosystem and tools aren't really there to serve those sensibilities well currently, and it's harder than it needs to be.
While I don't know anything about things like the avionics of a miltary aircraft, COTS is at least used to handle TS data and is at least *present* as part of the standard buildout of many vehicles.
So not only do COTS components play a role, they play mission critical roles.
Further, when we say 'components' we don't mean merely things like resistors, we are talking about full circuit boards complete with critical security related firmware, if not the whole system (though the whole system isn't really that much more risky than complete motherboards).
The ship has pretty much sailed for any semblance of diversity of sourcing electronics. The government is left having to do 'secure' looking gestures without being able to address real threats in any significant way.
Practically speaking, we see fixes all the time. Occasionally there is 'glitchy' behavior that is somehow useful, but the vast majority of the time, glitchy behavior has no practical use. As you say, there are examples, but in your example they don't dare fix it, which is evidence that some groups care about compatibility, even if it didn't behave the way they meant for it to behave. In such a case, you decide either 'a', the desired behavior wasn't needed or 'b', implement a new function to supersede with the desired behavior and be forever left with the 'wrong' version of the function.
Note that I agree with you, however people going after copr or ppa sorts of repositories have equal amounts of ability to screw over a system. The general impatience that leads to using the free0for-all package manager associated with a language will also lead to a free-for-all of yum/apt repositories.
Of course, the quality of rollback solutions is higher with the distro manage, hence my agreeing with you, but the problem is still complex beyond just using the crappier package management.
If you are using something like npm, odds are the rpm databse is only a vaague hint of what a fraction of the system used to look like. That admin is already down the path of ignoring the OS packager, so expectation that it will repair completely is low.
Easy, because there's a large body of content saying "it's ok to do all that stuff, because continuous delivery!".
Some people will say "but that's not what it means" and some of those will have very reasonable implementations and call it that. While they are doing right by themselves and their team, they only make the problem worse because others see 'success' and decide that downloading and random code in production is ok, because this other guy did it and it seemed to work out.
If a system is "in production" but using npm to manage it, that backup database is not particularly relevant to the state of the system. I have seen projects that say to install an rpm, then immediately start modifying parts of it becuase the developer wanted to customize. Use of the package manager means discipline, and using npm to deploy stuff as admin represents *not* having that discipline.
That's a problem in and of itself. There's no sane reason for such a small function to be a library all it's own, rather than coordinated in a larger, cohesive project.
When I ship software, the "language packager" is my first step to make a distro package. However, a large contingent of my users use the language package management to get the applications to use directly, despite having zero developer interest.
Eh, not really, except *maybe* the rust situation, but even that has been accommodated (by having the major version of a package embedded in the name of the package).
First, the general answer that 'locks on to versions' is a recipe for security and bug nightmares. In that universe, no longer is it feasible for a foundational library to fix the problems they caused all on their own, becuase the apps statically linked. An openssl tweak means the world has to be rebuilt becuase everyone baked it in instead of relying upon the contract of a major version.
One of the main problems is that developers have no interest in anything that would constrain them, and honoring a contract where they fix things in an API and ABI compatible way is just such an annoyance they won't bother with. By extension, they don't want to ever promise that 2.1.2 will be compatible with 2.1.1. The fix for this has thus far professional linux companies paying people to do the 'boring' work of back-porting fixes to declared stable development bases.
However, there are practical limits to what the enterprise distros can do, so inevitably, there is going to be a body of assets out there with attractive features, but no one backing it. This seems 'fine' to a new developer and they ride the wave. Until that wave crashes, and their app depending on 'foo' causes a problem when foo went to 2.1.2 from 2.1.1 and broke compatibility. This pain is inflicted enough they say "that's it" and put in their requirements "we require *exactly* foo 2.1.1", and they start doing this proactively on all their packages.. Rather than targeting a 'stable' release, they target an arbitrary "it seemed to work at the time version", with no one supporting that particular vintage. They then move on, forgetting entirely about the project that now bores them, and all the security and other bug fixes that happen after 2.1.1 are denied to users of that app. The concept of installing multiple applications in the same namespace becomes impossible, as they all start depending on versions that are mutually incompatible.
Essentially, the ugly mess that is npm, pypi, etc is a symptom of a much bigger problem, a lack of discipline in major projects. The result is either an unusable mess or a dangerously unmaintained stack. Note that this is not a 'young folk' problem, there are plenty of people getting into the market recognnizing the problem and sticking to technology choices that sidestep it. The problem is the people who do try and fail to ride the wave of random software updates are very *loud* about their problems, and their problems simply must be solvable using some technology, not having to adjust or be mindful of the policies of the teams that back the tools they want to use.
Javascript suffers more due to the reluctance of extending the base for utterly common tasks, causing people to invent frameworks and libraries to do things like simple string formatting, which is standard in *every* other language, but not javascript.
Slashdot Mirror
Partisanship, sadly, is going to continue to dominate for the same reason team sports play and people get invested in their 'team' that they really have nothing to do with.
It's much easier to blindly declare some 'team' affiliation to show how much you care and react to the specific candidate when something like a horrible scandal happens. Otherwise you can look engaged without having to be remotely thoughtful.
I use my laptop to connect to datacenter equipment, with a usb serial port and/or an ethernet cable.
I use it to connect my phone, generally not at the same time.
HDMI I frequently use for conference rooms and presentations.
I currently have a laptop with no ethernet port, and the dongle is such n annoying problem that I will absolutely have a built in ethernet port. An associate has a macbook and in meetings never is the one to present, because the conference rooms never has usb-c and he never has the right dongle with him.
For me, I like the concept of USB-c connector for keyboard/mouse/displayport/ and charge in one port, but I would additionally want at least one USB-a connector, HDMI, and Ethernet jack Maybe in a few years HDMI will get replaced by USB-c (once upon a time, I *needed* VGA, no more), maybe accessories will move to type-c (the more complex and expensive 24 pin usb-c connector adds non-trivial cost to little usb accessories though) but even then I'd want at least two ports. RJ-45 however is going to be with us for the foreseeable future (the cable and connector are just too dirt cheap)
Originally, it was about "you want a super sleek laptop, compromises ok".
Then it lost all meaning as the mainstream went that thin, including apple's own line.
Now taking it at face value, looks like the new meaning will be "ok, fine, we'll play in the budget space". Note their mentioning boosting units sold, this is presumably to try to up their share of the market.
Apple may be buying into what seems to be the general perception in the market: PC market is not going to irrelevance, the relationship between tablet/laptop/phone has somewhat stabilized and PC market turns out to be more lively than tablet.
Does it really sell that well in corporate? I mean apart from one notable anti-microsoft company, I've always seen corps stick to the market where they can make Dell and HP and Lenovo go into a bid war and they don't give a crap about brand value.
Now maybe this upcoming Macbook Air will be cheap and marks Apple actually giving a damn about their share on the busniess PC, but so far they've not acted that way.
This phenomenon is to be expected, sadly, as the mass market appeal diminishes.
For a time, high end computer and what the general market needed overlapped very nicely, and the high volumes made high end computing very affordable.
Now the general market is served by a pretty distinct set of configurations, and the high end of the market goes back up.
I don't think it's that special. It's just that when someone does get sick, it's pretty quick and very pronounced. I don't think I've ever seen a 'percentage' study, mostly anecdotes. As such anecdotes where people feel like they are going to throw up are for more potent than anecdotes where nothing happened.
My wife gets sick just seeing content on the tv that spins around and such, but she can do VR without issue... so long as movement is 1:1.
Of course she doesn't really *care* to, but her disinterest is not due to physical reaction.
That is not a problem for everyone and is even unheard of for certain sorts of experiences (experiences with 0 in-game movement that isn't 1:1 don't make people sick, games with cockpits don't make many people sick, a free-movement fps can make a lot of people sick, but there are a lot of people not in that boat. For example there has not been a VR experience *yet* that perturbed me in the least.
However, current tech is limited and flawed (resolution, optics, weight). It does demand a fair amount of space to participate in. I can be a problem socially where the more blatant isolation is seen as offensive. There are reasons why VR may not take off, but I don't think the sickness is a fatal problem for the industry.
My point is that Apple is of sufficient scale that they already have international distributed data centers. Given they already feel the need to have such a footprint, the incremental cost to do it in-house versus outsourcing for most companies in that position would be lesser than renting the capacity.
I do know of a couple of companies that look at the cost and kick themselves, seeing that their up front decision to cloud host ended up being more costly than in-house, but so would be the cost of migrating, so they are stuck paying higher amounts on an ongoing basis.
Apple has a quarterly profit that exceeds most companies annual revenue at this point, so they have the cash flow to overcome such hurdles, unless their internal IT is just hopeless, they should be able to do a lot to seek the lowest overall cost. By the same token, Apple is on such unbelievably solid ground that they don't need to go by the 'assets are a bigger liability than expense, even if having to spend more money' philosophy that other companies are often stuck with.
They do, however, buy third party servers for their infrastructure, including parts of iCloud hosting.
I would have also expected Apple to have more in-house cloud hosting, as *generally* when you get to very large scale, it becomes cheaper to own it rather than to rent it in absolute terms. From a capital expense versus operational expense, there is still a set of companies that are very averse to having capital, but Apple doesn't strike me as being in a position where they should have to fret about having too much capital.
I can't quite dig up *that*, but there is some content around the same time period talking about '144 mbit' versus the 300 mbit theoretical max, so it seemed that about the same time in development, they were saying 'about half'.
Now this is saying the about half was too optimistic, and instead 1/6th turned out to be the case. If the same carries over to this, then we would still be talking about 150 mbps. In other words, what was hyped for LTE 'real-world' may be the '5G' real-world.
Of course, this *could* be a more realistic simulation and maybe there is a lot of headroom, but historically speaking that's never been the case.
The weird part is the proprietary gas payment apps in lieu of putting in chip readers.
Like if I want to pay for gas with my phone at a shell station, I would *have* to have a Chase credit card.. for some reason.
Exxon has a more open ended payment app, and to their credit it works... most of the time.
Even Obama himself has expressed the thought that it didn't make a lot of sense. He basically got a prize for the combination of not being George W. Bush and for being first black US president, with some rationalization around him being aligned the right way for a Nobel Peace prize. It's not to say his efforts weren't in the right direction, but there were probably more deserving candidates.
I will concur that this is a whole new level of wrongness. Even if you were of the mindset that he did 'save the internet' (which I find to be absurd), it seems out of place for the NRA to be in the place of awarding a gun based on that, as it doesn't really align with any of NRA's agenda.
Yeah, the "don't reinvent the wheel" is extreme.
I would figure by now there could be libraries of many functions, with a build tool to strip out disused functions as part of minification. Even if things stayed as poor as the code seeing distinct files, would think there would be curated collections of these things rather than a free-for-all repository, where authors can update, add, replace, and remove as they like.
Of course, one would have also hoped the language to get more standard library functionality, having a richer environment built into the browsers rather than having to read big runtimes from the internet all the time.
Maybe the mindset of the loudest contingent of the JS community is just not suited to maintainable ecosystem, but at least there do exist those careful about this sort of thing. Unfortunately it seems the ecosystem and tools aren't really there to serve those sensibilities well currently, and it's harder than it needs to be.
While I don't know anything about things like the avionics of a miltary aircraft, COTS is at least used to handle TS data and is at least *present* as part of the standard buildout of many vehicles.
So not only do COTS components play a role, they play mission critical roles.
Further, when we say 'components' we don't mean merely things like resistors, we are talking about full circuit boards complete with critical security related firmware, if not the whole system (though the whole system isn't really that much more risky than complete motherboards).
The ship has pretty much sailed for any semblance of diversity of sourcing electronics. The government is left having to do 'secure' looking gestures without being able to address real threats in any significant way.
Practically speaking, we see fixes all the time. Occasionally there is 'glitchy' behavior that is somehow useful, but the vast majority of the time, glitchy behavior has no practical use. As you say, there are examples, but in your example they don't dare fix it, which is evidence that some groups care about compatibility, even if it didn't behave the way they meant for it to behave. In such a case, you decide either 'a', the desired behavior wasn't needed or 'b', implement a new function to supersede with the desired behavior and be forever left with the 'wrong' version of the function.
Note that I agree with you, however people going after copr or ppa sorts of repositories have equal amounts of ability to screw over a system. The general impatience that leads to using the free0for-all package manager associated with a language will also lead to a free-for-all of yum/apt repositories.
Of course, the quality of rollback solutions is higher with the distro manage, hence my agreeing with you, but the problem is still complex beyond just using the crappier package management.
It is of course that, but it is more than that and implements much of the windows 'userland' libraries.
In the WSL, they stopped at implementing the linux system calls, and the linux userland has to come from a linux distro.
If you are using something like npm, odds are the rpm databse is only a vaague hint of what a fraction of the system used to look like. That admin is already down the path of ignoring the OS packager, so expectation that it will repair completely is low.
It's really ubunutu that popularized sudo as 'the way'.
To be fair, the order of the day prior to that was that people logged in as root to avoid the hassle, sudo is better than that.
To those suggesting 'su is better' or 'ssh root@localhost' is better, any popularized approach would ultimately land in the same land of abuses.
Of course unless you setup sudo :NOPASSWD, that's just stupid and not the way any of those things come by default.
Easy, because there's a large body of content saying "it's ok to do all that stuff, because continuous delivery!".
Some people will say "but that's not what it means" and some of those will have very reasonable implementations and call it that. While they are doing right by themselves and their team, they only make the problem worse because others see 'success' and decide that downloading and random code in production is ok, because this other guy did it and it seemed to work out.
If a system is "in production" but using npm to manage it, that backup database is not particularly relevant to the state of the system. I have seen projects that say to install an rpm, then immediately start modifying parts of it becuase the developer wanted to customize. Use of the package manager means discipline, and using npm to deploy stuff as admin represents *not* having that discipline.
That's a problem in and of itself. There's no sane reason for such a small function to be a library all it's own, rather than coordinated in a larger, cohesive project.
When I ship software, the "language packager" is my first step to make a distro package. However, a large contingent of my users use the language package management to get the applications to use directly, despite having zero developer interest.
Eh, not really, except *maybe* the rust situation, but even that has been accommodated (by having the major version of a package embedded in the name of the package).
First, the general answer that 'locks on to versions' is a recipe for security and bug nightmares. In that universe, no longer is it feasible for a foundational library to fix the problems they caused all on their own, becuase the apps statically linked. An openssl tweak means the world has to be rebuilt becuase everyone baked it in instead of relying upon the contract of a major version.
One of the main problems is that developers have no interest in anything that would constrain them, and honoring a contract where they fix things in an API and ABI compatible way is just such an annoyance they won't bother with. By extension, they don't want to ever promise that 2.1.2 will be compatible with 2.1.1. The fix for this has thus far professional linux companies paying people to do the 'boring' work of back-porting fixes to declared stable development bases.
However, there are practical limits to what the enterprise distros can do, so inevitably, there is going to be a body of assets out there with attractive features, but no one backing it. This seems 'fine' to a new developer and they ride the wave. Until that wave crashes, and their app depending on 'foo' causes a problem when foo went to 2.1.2 from 2.1.1 and broke compatibility. This pain is inflicted enough they say "that's it" and put in their requirements "we require *exactly* foo 2.1.1", and they start doing this proactively on all their packages.. Rather than targeting a 'stable' release, they target an arbitrary "it seemed to work at the time version", with no one supporting that particular vintage. They then move on, forgetting entirely about the project that now bores them, and all the security and other bug fixes that happen after 2.1.1 are denied to users of that app. The concept of installing multiple applications in the same namespace becomes impossible, as they all start depending on versions that are mutually incompatible.
Essentially, the ugly mess that is npm, pypi, etc is a symptom of a much bigger problem, a lack of discipline in major projects. The result is either an unusable mess or a dangerously unmaintained stack. Note that this is not a 'young folk' problem, there are plenty of people getting into the market recognnizing the problem and sticking to technology choices that sidestep it. The problem is the people who do try and fail to ride the wave of random software updates are very *loud* about their problems, and their problems simply must be solvable using some technology, not having to adjust or be mindful of the policies of the teams that back the tools they want to use.
Javascript suffers more due to the reluctance of extending the base for utterly common tasks, causing people to invent frameworks and libraries to do things like simple string formatting, which is standard in *every* other language, but not javascript.