As much as I would love for that to be the answer, I have to confess that it just isn't feasible.
-Game support. Valve has done a lot to change this, but a great deal of gaming is still Windows exclusive. Even in some open source programs that do support Linux, the Windows version is vastly better (e.g. PCSX2 graphics plugin for directx is actually usable, whereas the opengl one really isn't). -Network streaming support. Netflix and now Amazon prime at least can no longer run in linux. For the time being, Hulu still can but amazon prime at least shows that it's highly likely to evaporate.
Besides, just as Windows 8 lost its mind with a seemingly desperate UI experiment, you have Gnome 3 and Unity presenting some of the same issues (though with the option to completely swap out for KDE, MATE, etc if desired).
The issue is that WinRT has to offer *something* that IOS and Android do not in order to gain share.
They didn't pursue lower price, their offerings are no less expensive than Apple.
The didn't pursue better specs. They focused on Tegra 3, which is respectable but dated. Their screen resolution is downright atrocious compared to comparably priced products. While Android and IOS both have high ppi displays, MS has been left behind on this front.
They don't have more apps. Android and IOS had to build their ecosystems from scratch, but they had early mover advantage. After letting that situation simmer for years, they release a product with a paltry number of apps despite having a legacy of the most application compatibilty of any platform. They don't even have app compatibility between their phone and winrt as it stands (though that wouldn't have helped *much*, it still is a sign that they made a mistake compared with the strategies of Apple and Android).
Basically, every possible advantage that MS could have brought to market, they failed to do so. Like it or not, their best hope was/is to focus on x86 solutions where their application compatibilty can really come into its own.
But even I can tell a world of difference between professional photographer with good equipment and random guy with a cell phone.
Embedded camera in cell phone is necessarily restricted in terms of optics. You can play with the sensor all you want, but the optics simply cannot do the sorts of things a good camera can do.
There is still a lot of things that require some knowledge in operating a camera in order to get a good photo.
For the vast majority of even HPC code, it means compiler rework and math library development. The vast majority of benefit can be achieved with a drop in of a new library without rebuild of the application. In your example, it would be the interpreter, which actually tend to be the last things to receive this attention.
I'd consider the fact that the most demanding android applications are arm specific in terms of compile is the more critical thing.
Intel does have a product with high core count, Phi has 50 cores for example.
I haven't seen a lot of evidence that ARM under load offered better price performance than Intel before. The only thing making that claim I can recall committed a grevious mistake, measuring ARM power usage and then assuming TDP value rather than measuring x86 power usage. It was undeniable that under typical smartphone/tablet conditions Intel did horribly (mostly 'idle' but immediately able to do things on demand), and that seems to have been the engineering focus this time, a shallower sleep state that's possible without screen blanking is one notable facet.
While Intel's prospects in the mobile arena are slim (Andorid has a lot of momentum, and that momentum is largely tied to ARM in much the same way as Windows is tied to x86), I suspect they will continue to rule the roost in the datacenter and workstation-like workloads.
I'm saying robbing the user of the control is bad. A lot of workflows got crippled.
For example, it is common for me to hit a slow loading website and tab-away to do something else for a second. In Metro IE, tabbing-away stops the loading activity.
In therms of fostering app developers who fail to properly tombstone, if android ecosystem has taught us anything is that developers are content to churn out shoddy work and never care. A platform that *forces* the developer to do more work isn't a defensible feature when an alternative model has existed for decades without a lot of issue.
The task switcher is only a gui nicety. Look in an aftermarket task manager. Swiping away does not kill it necessarily, it just removes it from display. , Conversely, just because you see a screenshot of it, it still might have been killed by the OS and switch back will be a start over. The ICS last application UI acts like its previous incarnation, except it scales to more apps, allows swipe to remove elements, and has thumbnail screenshots (*not* live preview as WebOS had, for example).
At least in ICS, this is the case. I don't have any Jelly Bean device to look at its behavior. Maybe the swipe to kill works now, but I would be massively surprised if Android ever removes its 'kill on a whim' design.
The music industry situation was different. At the time the market went to drm-free by a landside, music playback devices by and large had no wireless or cellular radios. They were fixed-function devices that could only consume non-executable content (mostly). In that ecosystem, supporting multiple platforms was difficult to the point of being unfeasible. For the no-name cheap devices, DRM was completely out of reach. Customers more keenly felt the pitfalls of DRM given the state of the ecosystem. Even if each publisher *could* put their content into walled garden apps, the nature of how music is consumed suggests back to back playback of arbitrary selections from a customers library over the course of minutes. Also, ripping CDs was trivial for even casual users.
The state of devices used for reading and movie playback are generally internet connected and companies can deploy their own content management application. Having to navigate and switch between the applications is less disruptive relative to how much time the consumer is going to spend in one specific work. Scanning books in is in no way feasible as a casual endeavor comparing with CD ripping. All the 'no name' devices that are available are android devices meaning DRM is feasible.
I'd like to think that the music industry went mostly DRM-free because they saw it as the non-evil way to go, but it was more about feasibility and the CD market pretty much leaving the barn door open, rendering it a silly exercise to DRM protect content that is trivial to rip in other ways.
Have been greatly exaggerated. Phones and tablets have largely been a distinct market. I don't think it has really had any particular effect on PC or laptop market.
I'm willing to beleve that *sales* of x86 systems to the consumer market have slowed. I think though that *usage* hasn't decreased appreciably. x86 ecosystem got 'good enough' for the vast majority of market and performance needs no longer drive demand. I think this would have been the reality with or without android/ios/etc.
It does reaffirm that Ubuntu just does not care about the desktop model at all. That was self-evident from the crap of Unity and Mir though. It further erodes what little respect I had for the distribution. They are chasing market opportunity more than trying to provide value to their users. It's sad on both ends. On one end, their once respectable desktop experience has languished. On the other end, their attempts to get into televisions and phones have been pretty pathetic.
I did not see whether they address the Metro apps just quitting by themselves when in the background
I'd be exceptionally surprised if they change this. That was an intentional design goal with a lot of effort in it. It's infuriating as it is bringing over one of the worst aspects of android and ios, piss poor multitasking. The thinking being that 'task management' is scary and if an app developer goes through some hoops, they should be able to restore state if killed. In practice, developers are too lazy to properly handle that use case and a task switch away and back might get you back where you were or it might start the application over without any persisted state depending on the effort of the developer and hard to predict decisions by the platform whether to suspend it or kill it.
The major goal, of course, to automatically guess what the user would want and 'save' them from having to close apps when memory is in short supply. The 'SIGSTOP' in background is annoying enough, but is marginally more defensible in the name of saving power.
I've had this debate time and time again with some evangelical Christians. I put to them the reality of a person never introduced to their faith. A man who conducts his life in every way a manner consistent with doing good works as prescribed by Jesus without ever actually knowing that Jesus existed at all. I ask if in their faith, that man is damned to hell for is ignorance of their faith. More often than not, they actually come back and say outright that the man would be damned to hell as 'the only way to heaven is through Christ'. By the same token, growing up I was basically taught that being baptized was pretty much the only hard requirement, and that everything else was, for lack of a batter word 'negotiable''. Christianity would allow forgiveness for a multitude of sins, except for faith in Jesus as divine.
Even the current pope has come out now with the respectable message that a man's will to do good matter even if they consciously choose to be an Athiest, but there are a *lot* of Christians who do not feel that way.
Besides, I'm not confident in the integrity of the specifics of the words of Jesus surviving history intact. He may have never made such a claim until someone posthumously put words into his mouth. He may have made no personal claims to divinity and such claims are really the belief of another. So much of those words spent a long time as oral tradition before being put to paper, and even then there's opportunity for thins to be changed as they were transcribed and translated.
I said 'in practice'. In theory, there are specifics. In practice, the terminology is hijacked by project managers as they see fit more often than the specific set of things are implemented.
Of the last published top500 list, 7 out of the top 10 had no GPUs. This is a clear indication that while GPU is defintely there, claiming 'Most of the actual processing power' is overstating it a touch. It's particularly telling that there are so few as overwhelming the specific hpl benchmark is one of the key benefits of GPUs. Other benchmarks in more well rounded test suites don't treat GPUs so kindly.
This isn't to say that ARM *can't* be there, but thus far all of the implementations have focused around 'good enough' performance within a tightly constrained power envelope. Intel's designs have traditionally been highly inefficient in that power band, but at peak conditions, it is still compelling.
I recall one 'study' which claimed to demonstrate ARM as inarguably better. It got way more attention than they should have. The reason being is that they measured the performance on the ARM test, but just *assumed* TDP would be the accurate number for x86. There are very few workloads that would cause a processor to *average* TDP over the course of a benchmark.
The thing that really *is* stealing x86 thunder is the GPU world. Intel's Phi strives to answer it, but thus far falls short in performance. There continue to be areas where GPU architecture is an ill fit, and ultimately I think Phi may end up being a pretty good solution.
Whether it was 'waterfall', 'agile'', or whatever, every project that I've worked with that seemed to put more effort into using the most hyped phrasing to describe their process than into actually developing the project has been doomed.
I liken it to religion. The spirit of most holy texts is quickly lost in the actions of adherents as they focus on the specific content rather than the message. For Christianity, specific belief in the divinity of Jesus seems to often be more important than adhering to his teachings. Similarly, in Agile, managing to map words like 'scrum', 'sprint', 'epic', 'user stories', and so on to what you do is more important than internalizing the original intent behind those words.
Projects that don't make a lot of effort to 'conform' to any specific renowned fad tend to do well. They also tend to do the sorts of stuff Agile advocates without using the words.
Being called 'Agile' doesn't mean that it is in the spirit or letter of 'Agile'.
The reality is that 'Agile' is in practice more of a brand than anything else. Project Managers love to apply the terminology to their projects. This does not mean they actually meaningfully follow a consistent set of behaviors, just that they use similar sounds words.
'Agile' is like 'Cloud' and 'Web 2.0'. While each phrase may have coined with a particular specific concept in mind, they became more hype than anything usefully descriptive.
I think you can find instances of every carrier sneaking rate hikes onto customers with contracts. The contract only helps the carrier, never ever the consumer.
Thankfully, my contract is up next month. I'll be off to T-mobile no-contract plan.
How do you acquire materials for your 3d printer? How do you acquire food? What about software? What about movies and music? There is so so much more to the economy than the area that 3D printers cover that you can't say money or some equivalent mechanism is 'obsolete'.
For one, most of the work still done by humans is so still far away from the realm of what AI and machinery can do. Anyone who thinks otherwise greatly overestimates the nature of AI they've seen and underestimates how very alien simple day to day things are relative to the state of the art in AI.
For another, this progress is going to be curtailed for the same reason why desktop market is plateauing. Even if we *could* get there, we don't have the collective will to advance technology. There are people talking about the relatively hard wall physics presents in various fields we will bump into, but I suspect we won't even get that far as the 'good enough' situation will make it unprofitable to even get that close. It's increasingly difficult to justify high power designs that niche markets still need that formerly got to come along for the ride with mass market amortizing the cost.
Finally, I think as a collective whole, we don't *want* it. We have spent millennia fostering cultures that largely have us value ourselves and each other in terms of the work we do. We don't know how to do anything else. We have no other way that has worked of deciding how to divvy up resources among ourselves.
I still use links (not lynx) in very select cases (basic navigation from a shell on a server), but mostly I accept that modern browsers have little downside.
I gave up pine because just too much content I receive cannot be rendered without it in my professional correspondence and integrated calendaring becomes a must. However, for a lot of cases it is hard to beat the simplicity of pine or mutt.
Terminals have always been and will continue to be a fact of life *if* you are going to go into IT/programming as a profession. A critical focus area of MS has been making cli/scripting more competent, so even they recognize it.
As new technology comes along, you have to eye it critically. It may be empty hype or it may carry value. Sometimes it is worse than your favorite approach, but the reality is clear that your favored strategy *will* lose. In that case it may be best to go ahead and try to improve the inevitable winner. Sometimes its better to not assume what everyone thinks to be the winner is inevitable and push hard for what you believe to be better and make the case. Sometimes even if the new thing is objectively a little better than what you have in place assuming you didn't have either implemented, the worse solution winds by being good enough, already done, and risks an faults known.
Basically, if you want to be in the industry, you have to be constantly monitoring change, assessing whether it will be good as-is or perhaps is amenable for your guidance to change, or sometimes rejecting it even as everyone around you *thinks* otherwise. A career in the industry is a career of unending vigilance.
Of course, I strongly hope my own child will not want to get into this field. It can be rewarding but it is frankly exhausting never knowing if the next bend in the path will leave you hopelessly irrelevant. You have to know everything about anything so that you can jump on the next opportunity should it dry out.
I think a software developer should proceed in order working with the components comprising a modern software stack.
Start with fiddling a bit with breadboards and basic circuits.
In relatively short order, move on the assembly programming for maybe half a year.
Then, get comfortable with C level development, understanding all the syntax shortcuts for what you formerly had to do, but by and large still being able to easily tell how it maps to your assembly effort. The bulk of the educational aspect should be spent in C.
Then they should touch perhaps Erlang and Lisp. At least a couple of languages with pretty interesting tendencies that display a line of thinking that diverges prettty strongly from the typical to give the developer a bit more context.
Near the end, move on to Python, C#, Java, and perhaps Powershell. Have some opportunity to explore the languages most likely to be directly relevant to their immediate career, understanding what sort of things they tend to take care of without you worrying, and what sorts of strategies end with those facilities not providing adequate help (e.g. scenarios that muck up things for reference counting).
I'm not even that old, but have taken a perverse interest in understanding the low level implications of everything I do. Certainly, most of the time I don't have to think too hard about it, but the awareness has been very useful more frequently than one might think.
I think that low level understanding helps me to adapt to higher level language features as they come out. People who don't understand the low level stuff seem to regard their craft as some sort of unfathomable magic where they learned how to apply a particular generation of technologies without truly understanding it. When a new language feature comes out, if you understand the low level well, you have a pretty solid feeling to understand what that feature is doing and how to exploit it.
Unless a curriculum is touching all of this, low level and high level and the nitty gritty of how it comes together, i don't think it is constructing durable skills.
netsh is not a powershell cmdlet. write-output is explicitly for converting objects into a screen-readable format, and is used on the end of a pipe.
My point is that programmers have to play by the rules and a lot of stuff commonly done in powershell is older stuff and done by less than thorough developers.
lack of convenience in Linux for implementing signing is pretty irrelevant... that is a Linux flaw, not a powershell problem.
It means MS didn't use any existing standard for signing and had a new ASN.1 formatted structure. It's an example of MS ignoring industry standards to do the exact same thing in an incompatible, proprietary way.
The SSD part uses an undocumented format for caching
Fun thing about non-volatile cache, there is nearly zero pressure to push from cache to disk and certainly one large point of this is to have write-back cache with arbitrarily long delay to commit.
I say 'nearly' zero since there is still a desire to have space amenable to be rewritten as soon as possible (in the same way modern OSes proactively write page-out candidates to swap so that they may be evicted without delay), but the urgency is not there like it is with memory backed cache (both because of volatility and the rather generous amount of extra space in SSD).
I suspect the 'disk' is still just a block manager (well, disk(s)) that doesn't have any awareness of the FS, just the driver half that makes it 'look' like one volume 'transparently'.
This is of course similar to 'fakeraid' with all the potential trappings thereof. If it presents as two disks otherwise or something similar in a standard way (and the driver is just to deliver product ahead of the standardized implemention being available) that might not be too bad.
Slashdot Mirror
As much as I would love for that to be the answer, I have to confess that it just isn't feasible.
-Game support. Valve has done a lot to change this, but a great deal of gaming is still Windows exclusive. Even in some open source programs that do support Linux, the Windows version is vastly better (e.g. PCSX2 graphics plugin for directx is actually usable, whereas the opengl one really isn't).
-Network streaming support. Netflix and now Amazon prime at least can no longer run in linux. For the time being, Hulu still can but amazon prime at least shows that it's highly likely to evaporate.
Besides, just as Windows 8 lost its mind with a seemingly desperate UI experiment, you have Gnome 3 and Unity presenting some of the same issues (though with the option to completely swap out for KDE, MATE, etc if desired).
The issue is that WinRT has to offer *something* that IOS and Android do not in order to gain share.
They didn't pursue lower price, their offerings are no less expensive than Apple.
The didn't pursue better specs. They focused on Tegra 3, which is respectable but dated. Their screen resolution is downright atrocious compared to comparably priced products. While Android and IOS both have high ppi displays, MS has been left behind on this front.
They don't have more apps. Android and IOS had to build their ecosystems from scratch, but they had early mover advantage. After letting that situation simmer for years, they release a product with a paltry number of apps despite having a legacy of the most application compatibilty of any platform. They don't even have app compatibility between their phone and winrt as it stands (though that wouldn't have helped *much*, it still is a sign that they made a mistake compared with the strategies of Apple and Android).
Basically, every possible advantage that MS could have brought to market, they failed to do so. Like it or not, their best hope was/is to focus on x86 solutions where their application compatibilty can really come into its own.
But even I can tell a world of difference between professional photographer with good equipment and random guy with a cell phone.
Embedded camera in cell phone is necessarily restricted in terms of optics. You can play with the sensor all you want, but the optics simply cannot do the sorts of things a good camera can do.
There is still a lot of things that require some knowledge in operating a camera in order to get a good photo.
For the vast majority of even HPC code, it means compiler rework and math library development. The vast majority of benefit can be achieved with a drop in of a new library without rebuild of the application. In your example, it would be the interpreter, which actually tend to be the last things to receive this attention.
I'd consider the fact that the most demanding android applications are arm specific in terms of compile is the more critical thing.
Intel does have a product with high core count, Phi has 50 cores for example.
I haven't seen a lot of evidence that ARM under load offered better price performance than Intel before. The only thing making that claim I can recall committed a grevious mistake, measuring ARM power usage and then assuming TDP value rather than measuring x86 power usage. It was undeniable that under typical smartphone/tablet conditions Intel did horribly (mostly 'idle' but immediately able to do things on demand), and that seems to have been the engineering focus this time, a shallower sleep state that's possible without screen blanking is one notable facet.
While Intel's prospects in the mobile arena are slim (Andorid has a lot of momentum, and that momentum is largely tied to ARM in much the same way as Windows is tied to x86), I suspect they will continue to rule the roost in the datacenter and workstation-like workloads.
I'm saying robbing the user of the control is bad. A lot of workflows got crippled.
For example, it is common for me to hit a slow loading website and tab-away to do something else for a second. In Metro IE, tabbing-away stops the loading activity.
In therms of fostering app developers who fail to properly tombstone, if android ecosystem has taught us anything is that developers are content to churn out shoddy work and never care. A platform that *forces* the developer to do more work isn't a defensible feature when an alternative model has existed for decades without a lot of issue.
The task switcher is only a gui nicety. Look in an aftermarket task manager. Swiping away does not kill it necessarily, it just removes it from display. , Conversely, just because you see a screenshot of it, it still might have been killed by the OS and switch back will be a start over. The ICS last application UI acts like its previous incarnation, except it scales to more apps, allows swipe to remove elements, and has thumbnail screenshots (*not* live preview as WebOS had, for example).
At least in ICS, this is the case. I don't have any Jelly Bean device to look at its behavior. Maybe the swipe to kill works now, but I would be massively surprised if Android ever removes its 'kill on a whim' design.
The music industry situation was different. At the time the market went to drm-free by a landside, music playback devices by and large had no wireless or cellular radios. They were fixed-function devices that could only consume non-executable content (mostly). In that ecosystem, supporting multiple platforms was difficult to the point of being unfeasible. For the no-name cheap devices, DRM was completely out of reach. Customers more keenly felt the pitfalls of DRM given the state of the ecosystem. Even if each publisher *could* put their content into walled garden apps, the nature of how music is consumed suggests back to back playback of arbitrary selections from a customers library over the course of minutes. Also, ripping CDs was trivial for even casual users.
The state of devices used for reading and movie playback are generally internet connected and companies can deploy their own content management application. Having to navigate and switch between the applications is less disruptive relative to how much time the consumer is going to spend in one specific work. Scanning books in is in no way feasible as a casual endeavor comparing with CD ripping. All the 'no name' devices that are available are android devices meaning DRM is feasible.
I'd like to think that the music industry went mostly DRM-free because they saw it as the non-evil way to go, but it was more about feasibility and the CD market pretty much leaving the barn door open, rendering it a silly exercise to DRM protect content that is trivial to rip in other ways.
Have been greatly exaggerated. Phones and tablets have largely been a distinct market. I don't think it has really had any particular effect on PC or laptop market.
I'm willing to beleve that *sales* of x86 systems to the consumer market have slowed. I think though that *usage* hasn't decreased appreciably. x86 ecosystem got 'good enough' for the vast majority of market and performance needs no longer drive demand. I think this would have been the reality with or without android/ios/etc.
It does reaffirm that Ubuntu just does not care about the desktop model at all. That was self-evident from the crap of Unity and Mir though. It further erodes what little respect I had for the distribution. They are chasing market opportunity more than trying to provide value to their users. It's sad on both ends. On one end, their once respectable desktop experience has languished. On the other end, their attempts to get into televisions and phones have been pretty pathetic.
I did not see whether they address the Metro apps just quitting by themselves when in the background
I'd be exceptionally surprised if they change this. That was an intentional design goal with a lot of effort in it. It's infuriating as it is bringing over one of the worst aspects of android and ios, piss poor multitasking. The thinking being that 'task management' is scary and if an app developer goes through some hoops, they should be able to restore state if killed. In practice, developers are too lazy to properly handle that use case and a task switch away and back might get you back where you were or it might start the application over without any persisted state depending on the effort of the developer and hard to predict decisions by the platform whether to suspend it or kill it.
The major goal, of course, to automatically guess what the user would want and 'save' them from having to close apps when memory is in short supply. The 'SIGSTOP' in background is annoying enough, but is marginally more defensible in the name of saving power.
I've had this debate time and time again with some evangelical Christians. I put to them the reality of a person never introduced to their faith. A man who conducts his life in every way a manner consistent with doing good works as prescribed by Jesus without ever actually knowing that Jesus existed at all. I ask if in their faith, that man is damned to hell for is ignorance of their faith. More often than not, they actually come back and say outright that the man would be damned to hell as 'the only way to heaven is through Christ'. By the same token, growing up I was basically taught that being baptized was pretty much the only hard requirement, and that everything else was, for lack of a batter word 'negotiable''. Christianity would allow forgiveness for a multitude of sins, except for faith in Jesus as divine.
Even the current pope has come out now with the respectable message that a man's will to do good matter even if they consciously choose to be an Athiest, but there are a *lot* of Christians who do not feel that way.
Besides, I'm not confident in the integrity of the specifics of the words of Jesus surviving history intact. He may have never made such a claim until someone posthumously put words into his mouth. He may have made no personal claims to divinity and such claims are really the belief of another. So much of those words spent a long time as oral tradition before being put to paper, and even then there's opportunity for thins to be changed as they were transcribed and translated.
I said 'in practice'. In theory, there are specifics. In practice, the terminology is hijacked by project managers as they see fit more often than the specific set of things are implemented.
Of the last published top500 list, 7 out of the top 10 had no GPUs. This is a clear indication that while GPU is defintely there, claiming 'Most of the actual processing power' is overstating it a touch. It's particularly telling that there are so few as overwhelming the specific hpl benchmark is one of the key benefits of GPUs. Other benchmarks in more well rounded test suites don't treat GPUs so kindly.
This isn't to say that ARM *can't* be there, but thus far all of the implementations have focused around 'good enough' performance within a tightly constrained power envelope. Intel's designs have traditionally been highly inefficient in that power band, but at peak conditions, it is still compelling.
I recall one 'study' which claimed to demonstrate ARM as inarguably better. It got way more attention than they should have. The reason being is that they measured the performance on the ARM test, but just *assumed* TDP would be the accurate number for x86. There are very few workloads that would cause a processor to *average* TDP over the course of a benchmark.
The thing that really *is* stealing x86 thunder is the GPU world. Intel's Phi strives to answer it, but thus far falls short in performance. There continue to be areas where GPU architecture is an ill fit, and ultimately I think Phi may end up being a pretty good solution.
Whether it was 'waterfall', 'agile'', or whatever, every project that I've worked with that seemed to put more effort into using the most hyped phrasing to describe their process than into actually developing the project has been doomed.
I liken it to religion. The spirit of most holy texts is quickly lost in the actions of adherents as they focus on the specific content rather than the message. For Christianity, specific belief in the divinity of Jesus seems to often be more important than adhering to his teachings. Similarly, in Agile, managing to map words like 'scrum', 'sprint', 'epic', 'user stories', and so on to what you do is more important than internalizing the original intent behind those words.
Projects that don't make a lot of effort to 'conform' to any specific renowned fad tend to do well. They also tend to do the sorts of stuff Agile advocates without using the words.
Being called 'Agile' doesn't mean that it is in the spirit or letter of 'Agile'.
The reality is that 'Agile' is in practice more of a brand than anything else. Project Managers love to apply the terminology to their projects. This does not mean they actually meaningfully follow a consistent set of behaviors, just that they use similar sounds words.
'Agile' is like 'Cloud' and 'Web 2.0'. While each phrase may have coined with a particular specific concept in mind, they became more hype than anything usefully descriptive.
I think you can find instances of every carrier sneaking rate hikes onto customers with contracts. The contract only helps the carrier, never ever the consumer.
Thankfully, my contract is up next month. I'll be off to T-mobile no-contract plan.
How do you acquire materials for your 3d printer? How do you acquire food? What about software? What about movies and music? There is so so much more to the economy than the area that 3D printers cover that you can't say money or some equivalent mechanism is 'obsolete'.
For one, most of the work still done by humans is so still far away from the realm of what AI and machinery can do. Anyone who thinks otherwise greatly overestimates the nature of AI they've seen and underestimates how very alien simple day to day things are relative to the state of the art in AI.
For another, this progress is going to be curtailed for the same reason why desktop market is plateauing. Even if we *could* get there, we don't have the collective will to advance technology. There are people talking about the relatively hard wall physics presents in various fields we will bump into, but I suspect we won't even get that far as the 'good enough' situation will make it unprofitable to even get that close. It's increasingly difficult to justify high power designs that niche markets still need that formerly got to come along for the ride with mass market amortizing the cost.
Finally, I think as a collective whole, we don't *want* it. We have spent millennia fostering cultures that largely have us value ourselves and each other in terms of the work we do. We don't know how to do anything else. We have no other way that has worked of deciding how to divvy up resources among ourselves.
I still use links (not lynx) in very select cases (basic navigation from a shell on a server), but mostly I accept that modern browsers have little downside.
I gave up pine because just too much content I receive cannot be rendered without it in my professional correspondence and integrated calendaring becomes a must. However, for a lot of cases it is hard to beat the simplicity of pine or mutt.
Terminals have always been and will continue to be a fact of life *if* you are going to go into IT/programming as a profession. A critical focus area of MS has been making cli/scripting more competent, so even they recognize it.
As new technology comes along, you have to eye it critically. It may be empty hype or it may carry value. Sometimes it is worse than your favorite approach, but the reality is clear that your favored strategy *will* lose. In that case it may be best to go ahead and try to improve the inevitable winner. Sometimes its better to not assume what everyone thinks to be the winner is inevitable and push hard for what you believe to be better and make the case. Sometimes even if the new thing is objectively a little better than what you have in place assuming you didn't have either implemented, the worse solution winds by being good enough, already done, and risks an faults known.
Basically, if you want to be in the industry, you have to be constantly monitoring change, assessing whether it will be good as-is or perhaps is amenable for your guidance to change, or sometimes rejecting it even as everyone around you *thinks* otherwise. A career in the industry is a career of unending vigilance.
Of course, I strongly hope my own child will not want to get into this field. It can be rewarding but it is frankly exhausting never knowing if the next bend in the path will leave you hopelessly irrelevant. You have to know everything about anything so that you can jump on the next opportunity should it dry out.
I think a software developer should proceed in order working with the components comprising a modern software stack.
Start with fiddling a bit with breadboards and basic circuits.
In relatively short order, move on the assembly programming for maybe half a year.
Then, get comfortable with C level development, understanding all the syntax shortcuts for what you formerly had to do, but by and large still being able to easily tell how it maps to your assembly effort. The bulk of the educational aspect should be spent in C.
Then they should touch perhaps Erlang and Lisp. At least a couple of languages with pretty interesting tendencies that display a line of thinking that diverges prettty strongly from the typical to give the developer a bit more context.
Near the end, move on to Python, C#, Java, and perhaps Powershell. Have some opportunity to explore the languages most likely to be directly relevant to their immediate career, understanding what sort of things they tend to take care of without you worrying, and what sorts of strategies end with those facilities not providing adequate help (e.g. scenarios that muck up things for reference counting).
I'm not even that old, but have taken a perverse interest in understanding the low level implications of everything I do. Certainly, most of the time I don't have to think too hard about it, but the awareness has been very useful more frequently than one might think.
I think that low level understanding helps me to adapt to higher level language features as they come out. People who don't understand the low level stuff seem to regard their craft as some sort of unfathomable magic where they learned how to apply a particular generation of technologies without truly understanding it. When a new language feature comes out, if you understand the low level well, you have a pretty solid feeling to understand what that feature is doing and how to exploit it.
Unless a curriculum is touching all of this, low level and high level and the nitty gritty of how it comes together, i don't think it is constructing durable skills.
netsh is not a powershell cmdlet. write-output is explicitly for converting objects into a screen-readable format, and is used on the end of a pipe.
My point is that programmers have to play by the rules and a lot of stuff commonly done in powershell is older stuff and done by less than thorough developers.
lack of convenience in Linux for implementing signing is pretty irrelevant... that is a Linux flaw, not a powershell problem.
It means MS didn't use any existing standard for signing and had a new ASN.1 formatted structure. It's an example of MS ignoring industry standards to do the exact same thing in an incompatible, proprietary way.
The SSD part uses an undocumented format for caching
Fun thing about non-volatile cache, there is nearly zero pressure to push from cache to disk and certainly one large point of this is to have write-back cache with arbitrarily long delay to commit.
I say 'nearly' zero since there is still a desire to have space amenable to be rewritten as soon as possible (in the same way modern OSes proactively write page-out candidates to swap so that they may be evicted without delay), but the urgency is not there like it is with memory backed cache (both because of volatility and the rather generous amount of extra space in SSD).
I suspect the 'disk' is still just a block manager (well, disk(s)) that doesn't have any awareness of the FS, just the driver half that makes it 'look' like one volume 'transparently'.
This is of course similar to 'fakeraid' with all the potential trappings thereof. If it presents as two disks otherwise or something similar in a standard way (and the driver is just to deliver product ahead of the standardized implemention being available) that might not be too bad.