So all the analysts put Oracle in the 'others' category, not enough revenue to even break out.
However, Cisco is the last 'big enough' vendor, and they seemed to have turned in under 4 billion in revenue on the server business.
But in any event, companies like IBM, Cisco, and Oracle are too profit obsessed to really live in a hardware business filled with competitors living with sub 10% margins.
On ZFS, while it may be hampered by license, there's sadly nothing that Oracle will gain by bothering to relicense it, unless it's part of a much friendlier open source stance to turn their image around, which seems to be something they aren't remotely interested in. I agree it's not worth the investment, just like everything else you listed, with respect to Oracle's culture.
Also, we have speculation here, is it just layoffs and keep working the product (the usual), abandoning all hardware, or just the SPARC side of things. I think most observers would agree it's worth giving up on the whole hardware division at this point, which is sad after the heyday of Sun roughly 2 decades ago, when people were excited to get a Solaris SPARC workstation.
Totality is amazing, but the partial solar eclipse is boring. It's slightly interesting in the dimming and the temperature drop, but frankly not that different from a cloud. Yes you can see a glowing crescent and it's different, but it is just not that interesting...
As much as I recognize the improvements slack provide, I'm right there with you with 'oh look, *another* messaging platform that thinks they'll not have their lunch eaten by a cheaper alternative'.
Chat has never been a particularly healthy area for long term commercial viability.
You can make a slack out of irc, but: -Consistent server side log with conversation replay (you can kind of sort of do it with ZNC, but it's hokey, and you never know if the person you are talking to has seen or not seen what you said prior to them joining). -Sadly, network security has settled on a magical decision that ports 80 and 443 are secure, but others are not necessarily so. It's nonsensical, but the reality. -Consistent assumptions about how clients are/are not rendering your markdown or whatever, notably pasting things like images or weblinks will behave consistently regardless of who you sent it to
So the biggest benefit IRC has is federation, which frankly isn't that helpful for smaller communities, and in fact netsplits make it more aggravating than helpful. A solution like mattermost is I think the best slack alternative. All the fancy webification and such people crave, no netsplits, and no cost and still open source.
Maybe in a very academic sense, but practically speaking P != NP is overwhelmingly assumed to be the case, even if not proven. A valid proof of that being the case would be some buzz in the academics of math, but the rest of the world would shrug and move on.
Actually as a long term tech site, there's a lot of both conservative skepticism around technology and enthusiasm around technologies at/.
So while there are plenty of comments talking about new thing X or thing that is old but somehow new again Y enthusiastically, there are plenty of folks with the skepticism and mocking.
Of course you are one of those young whipper snappers with an ID over 40,000, not some veteran user like I am;)
Unemployed looks worse than a 'programmer'. Realistically speaking, folks don't know what a candidate may mean when they cal themselves a 'software engineer' versus 'architect' versus 'programmer', because people self identify in various ways and are given various titles for similar work, so being in the general ballpark is going to get you in the door unless there's just an overwhelming number of candidates. Once in the door, then a more nuanced contemplation of your knowledge and experience happens.
But even then, generally people who are not known get hired for entry level positions, because even then it's risky to base a high paid position on someone based on assessment over the course of an interview. Certainly a lack of relevant work experience will lead to being saddled with jobs that are beneath you. Besides, in general people will get asked to do something that might be 'beneath them' and a candidate who seems too good to ever put up with that is a candidate who just isn't worth it, and refusing an entry level job in spite of lack of experience is certainly a way to prove that you might be frustrating.
I too had a huge hiccup at the.com bust. My situation forced me to took a really crappy low paying IT job, in fact I could have made more at a fast food place, but it was at least vaguely relevant to my career aspirations and I needed *some* way to pay for rent and expenses.
However, *having* that job enabled me to actually *get* a better job within 6 months.
Then that company tripped up, and again I took a not as crappy, but still crappy IT job. Again within 6 months, I was back to a decent job, which within 3 or 4 years became a six figure job doing solid work.
Those low paying "programming job"s are a necessary thing to get to success in the practical world, at least until you have some *significant* work experience to bolster your resume. And no, your dot-com experience wouldn't count because *everyone* had something impressive looking from those days and it was all but impossible to know if it meant anything or not.
So in all my prior conversations with folks advocating the approaches, the 'continuous delivery/integration' referred to reacting automatically to a commit. Triggering automation doesn't seem a particularly new concept to me. For example, software I deal with executes unit test on commits alongside human code reviews. Upon code review and unit test success, then a merge which triggers test builds for QA. Upon the human QA cycle and some external beta testers marking success, then a human triggers updates of appropriate things by pushing a signed commit. The emphasis is on actual humans with a reason to care but not a reason to be sympathetic to the developer to have a way to object. This is the element that certain developers have said is a waste of time and developers could manage their own situation without those voices 'mucking up' the process.
This is what people keep missing about 'AI' as it stands today. AI is a good approach for problems that are impractical to address with manual programming. Areas where programmers know the general algorithms that would be useful, but to describe how to apply them in a general chaotic dataset to order it would be incredibly complex. So we know various algorithms will find edges and glossiness and color and those are characteristics that appear in photos, but to describe how to apply all those techniques to identify a 'hot dog' in a picture is something beyond any practical application of manpower.
When dealing with structured data situations, human specified programming remains the order of the day. Machine Learning techniques help give structure to unstructured data so that programmers can make their moves. Continuous Integration (and deployment, though that's frequently a bad idea) are inherently in the realm of structured data, where current hyped AI techniques don't really have a role to play.
I'd say a large chunk of the problem is people churning out trivial 15 minute frontends to existing functionality being very loud and thinking too much of their perspective, drowning out the voices of people that work on more complex software.
Also, decision makers see more the impact of.css and it's very easy to make a sophisticated looking UI, which was formerly a viable indicator for someone at least had some sort of skill. The good thing is people who are more purely design minded can provide better quality, however the mindset of 'good looking gui' == 'respectable backend code' needs correction.
Again, not all software development is the same. A QA team in many situations is a team that cannot develop automated testing because they know how to use the software, not develop software. Because they represent the target customer base, not 'more development'. They provide a *distinct* perspective from what those skilled in software development can do for themselves. While automated testing can be done to assure that the various functions execute according to the design intent of the developer, usability may be utter crap and a QA team is the group to call the developers on it.
I have yet to see a shop that does continuous anything with a distinct team responsible for the automated testing. The QA team *is* the development team everywhere I have seen. The unit tests comprising the continuous integration are more often than not a joke.
Just because there are a gobton of 'ideas' that are 'yet another trivial frontend for a database' with fleeting interactions with users that can be stood up in a few minutes to an hour, this does not mean all applications can be reasonably have quality managed in the context of continuous delivery. Continuous Integration is fine and a solid approach that is fairly generally applicable across the board to shield a manual QA effort from asinine stuff, but a manual QA effort is still frequently warranted for complex applications with long term user experience concerns.
It's of limited utility so long as.vbs/.bat/.cmd still can run without such protections in the same context.
And on the 'you have to have admin rights', there is something deeply wrong with the Windows userbase. I made an app for Windows and made it available to some testers and went to see what they did. About 7 out of 10 of the test users right clicked to 'run as administrator' without even *trying* to run it normally. Even after telling them as the developer of the application that it does not need admin rights, 2 of them refused to run it normally, because they didn't believe that it could work without it.
'continuous delievery' is a term with a defined meaning. And releasing phone apps with unwanted UI/functionality in rapid succession is not part of that definition.
It is a natural consequence of a continuous delivery, emphasis on always evolving and changing and that the developer is king and no one can question developer opinion. Devolper decides it should move, it moves. No pesky human testers to stand up and say 'you confused the piss out of us' to make them rethink it. No automatic test is going to capture 'confuse the piss out of the poor non-developer users'.
If you have crashes on those nodes or customer complaints you roll back.
Note that a customer with a choice is likely to just go somewhere else rather than use your software. They'd actually have to care about your success to bother complaining if there is any hint of competition in the market.
The problem is that automated testing is no substitute for a QA team. This is fine for continuous integration, where the output is not considered production ready. A QA team consisting of people just like your real users who are paid to put up with your crap and complain rather than just go on to a competing product. Not people who know the code inside and out and are ready to help rationalize your design choices, but people who will challenge you, and rightfully tell you they don't give a shit that you think it's hard to do it the way that makes sense.
Continuous delivery is impossible to say that QA team still matters, as they have no ability to intervene when you go down the wrong path.
I don't see a reason why that would not work for embeded likewise.
Because 'crashes' and/or 'customer complaints' can mean people die in some of those cases, so saying 'rollback if it didn't work' is too late.
The crux of the problem is that we (in these discussions and the analysts) describe *all* manner of 'software development' as the same thing. Whether it's a desktop application, an embedded microcontroller in industrial equipment, a web application for people to get work done, or a webapp to let people see the latest funny cat video.
Then we start talking past each other, some of us terrified what 'continious delivery' means in the context of software in the microcontroller of a health care device, others thinking about amazon's shopping front and not seeing the big deal.
Also, there's the scope of changes. I know I hear familiy members complaining about various android apps shifting around and basically having to continually relearn stuff. Making small changes that may not even be noticed is one things, continually migrating navigation to a particular feature because you keep having 'better ideas' about what makes sense is maddening.
Of course the business behind it for externalized software development is software as a subscription is continual revenue, even if you don't have any compelling ideas to deliver value to the client that would otherwise make them cough up the money.
Of course a cmd/bat file can merrily do that as a prelude to an evil powershell script, so the execution policy is only annoying to legit users without being a significant problem to those that would use ps1 as an attack vector.
It would be maybe something if ps1 content could execute in some context that cmd/bat files could not (e.g. the way microsoft put activex everywhere), but they know better than to even try that. So they have something that would have mitigated problems they had with ActiveX, but also a reluctance to even risk it anywhere where ActiveX was a unique threat...
The powershell signing situation always baffled me.
To run a powershell script, you must sign it. Which is of course terribly inconvenient, but hey, at least it is secure.
Except you can disable the restrictions easily, so easily in fact that a would be attacker need only do one very minor thing prior to their script having to execute for all this to not matter, and that minor thing is readily accessible through a.bat or.cmd script (which I have seen professional software do even, temporarily relax the policy then re-enable when done, without a user having to approve/explicitly do it manually).
It's a way to vigorously say 'we were focused on security' and all the inconvenience for people to feel 'yep they thought about security' and arrive at a completely useless protection against attackers.
Having had a front row seat to one of those, they are afraid they'll look like ignorant idiots if they try to engage to open ended emails to their company. They are afraid of setting the expectation they could help via email, and then get judged poorly when they fail at trying. They might have an incredibly disparate set of products bearing their name.
I don't know them personally, but imagine if you emailed 'help@honeywell.com'. Honeywell has everything from little home space heaters to military UAVs to Airport landing systems. Such a company may be concerned that without some requiring some context, that they'll bumble the reply and it will look poorly.
Of course, a 'nice' thing would be software that analyzes and engages in a 'phone tree' like auto-reply if it can't figure it out. A nicer thing would be a few humans to sort it out.
It could be argued that even those user initiated notifications warrant a way of replying. For example I got an email notification of a password reset on an account that I did *not* ask for. In this case it was encouraged to reply if this was not the case, while also unable to continue without my assenting.
Anytime you receive a message toward one human, it just makes sense for that human to be able to reach back and engage with another human because the automated context may not always be what it seems.
Software can triage email coming in, and failing that, round robin the email to humans who may not know how to answer, but know their own company well enough to quickly bounce to someone who will.
Already email analysis is a fact of life (spam and phishing), having customer relationship management as part of that doesn't seem such a stretch.
So there's a class of companies in that category...
There is another class of company that uses 'no-reply' because they are fixated on a particular engagement model that forces issues into tracket tickets and set of tools to manage them that doesn't know how to deal with email. They don't trust the user to keep an email thread intact to allow someone to follow the history, or they don't have software they trust to translate email thread to a ticketing system.
Slashdot Mirror
Something smells about that number.
So all the analysts put Oracle in the 'others' category, not enough revenue to even break out.
However, Cisco is the last 'big enough' vendor, and they seemed to have turned in under 4 billion in revenue on the server business.
But in any event, companies like IBM, Cisco, and Oracle are too profit obsessed to really live in a hardware business filled with competitors living with sub 10% margins.
On ZFS, while it may be hampered by license, there's sadly nothing that Oracle will gain by bothering to relicense it, unless it's part of a much friendlier open source stance to turn their image around, which seems to be something they aren't remotely interested in. I agree it's not worth the investment, just like everything else you listed, with respect to Oracle's culture.
Also, we have speculation here, is it just layoffs and keep working the product (the usual), abandoning all hardware, or just the SPARC side of things. I think most observers would agree it's worth giving up on the whole hardware division at this point, which is sad after the heyday of Sun roughly 2 decades ago, when people were excited to get a Solaris SPARC workstation.
Totality is amazing, but the partial solar eclipse is boring. It's slightly interesting in the dimming and the temperature drop, but frankly not that different from a cloud. Yes you can see a glowing crescent and it's different, but it is just not that interesting...
As much as I recognize the improvements slack provide, I'm right there with you with 'oh look, *another* messaging platform that thinks they'll not have their lunch eaten by a cheaper alternative'.
Chat has never been a particularly healthy area for long term commercial viability.
You can make a slack out of irc, but:
-Consistent server side log with conversation replay (you can kind of sort of do it with ZNC, but it's hokey, and you never know if the person you are talking to has seen or not seen what you said prior to them joining).
-Sadly, network security has settled on a magical decision that ports 80 and 443 are secure, but others are not necessarily so. It's nonsensical, but the reality.
-Consistent assumptions about how clients are/are not rendering your markdown or whatever, notably pasting things like images or weblinks will behave consistently regardless of who you sent it to
So the biggest benefit IRC has is federation, which frankly isn't that helpful for smaller communities, and in fact netsplits make it more aggravating than helpful. A solution like mattermost is I think the best slack alternative. All the fancy webification and such people crave, no netsplits, and no cost and still open source.
Maybe in a very academic sense, but practically speaking P != NP is overwhelmingly assumed to be the case, even if not proven. A valid proof of that being the case would be some buzz in the academics of math, but the rest of the world would shrug and move on.
Actually as a long term tech site, there's a lot of both conservative skepticism around technology and enthusiasm around technologies at /.
So while there are plenty of comments talking about new thing X or thing that is old but somehow new again Y enthusiastically, there are plenty of folks with the skepticism and mocking.
Of course you are one of those young whipper snappers with an ID over 40,000, not some veteran user like I am ;)
Unemployed looks worse than a 'programmer'. Realistically speaking, folks don't know what a candidate may mean when they cal themselves a 'software engineer' versus 'architect' versus 'programmer', because people self identify in various ways and are given various titles for similar work, so being in the general ballpark is going to get you in the door unless there's just an overwhelming number of candidates. Once in the door, then a more nuanced contemplation of your knowledge and experience happens.
But even then, generally people who are not known get hired for entry level positions, because even then it's risky to base a high paid position on someone based on assessment over the course of an interview. Certainly a lack of relevant work experience will lead to being saddled with jobs that are beneath you. Besides, in general people will get asked to do something that might be 'beneath them' and a candidate who seems too good to ever put up with that is a candidate who just isn't worth it, and refusing an entry level job in spite of lack of experience is certainly a way to prove that you might be frustrating.
I too had a huge hiccup at the .com bust. My situation forced me to took a really crappy low paying IT job, in fact I could have made more at a fast food place, but it was at least vaguely relevant to my career aspirations and I needed *some* way to pay for rent and expenses.
However, *having* that job enabled me to actually *get* a better job within 6 months.
Then that company tripped up, and again I took a not as crappy, but still crappy IT job. Again within 6 months, I was back to a decent job, which within 3 or 4 years became a six figure job doing solid work.
Those low paying "programming job"s are a necessary thing to get to success in the practical world, at least until you have some *significant* work experience to bolster your resume. And no, your dot-com experience wouldn't count because *everyone* had something impressive looking from those days and it was all but impossible to know if it meant anything or not.
'FDA approves new treatment for ALL cancer'
So in all my prior conversations with folks advocating the approaches, the 'continuous delivery/integration' referred to reacting automatically to a commit. Triggering automation doesn't seem a particularly new concept to me. For example, software I deal with executes unit test on commits alongside human code reviews. Upon code review and unit test success, then a merge which triggers test builds for QA. Upon the human QA cycle and some external beta testers marking success, then a human triggers updates of appropriate things by pushing a signed commit. The emphasis is on actual humans with a reason to care but not a reason to be sympathetic to the developer to have a way to object. This is the element that certain developers have said is a waste of time and developers could manage their own situation without those voices 'mucking up' the process.
This is what people keep missing about 'AI' as it stands today. AI is a good approach for problems that are impractical to address with manual programming. Areas where programmers know the general algorithms that would be useful, but to describe how to apply them in a general chaotic dataset to order it would be incredibly complex. So we know various algorithms will find edges and glossiness and color and those are characteristics that appear in photos, but to describe how to apply all those techniques to identify a 'hot dog' in a picture is something beyond any practical application of manpower.
When dealing with structured data situations, human specified programming remains the order of the day. Machine Learning techniques help give structure to unstructured data so that programmers can make their moves. Continuous Integration (and deployment, though that's frequently a bad idea) are inherently in the realm of structured data, where current hyped AI techniques don't really have a role to play.
I'd say a large chunk of the problem is people churning out trivial 15 minute frontends to existing functionality being very loud and thinking too much of their perspective, drowning out the voices of people that work on more complex software.
Also, decision makers see more the impact of .css and it's very easy to make a sophisticated looking UI, which was formerly a viable indicator for someone at least had some sort of skill. The good thing is people who are more purely design minded can provide better quality, however the mindset of 'good looking gui' == 'respectable backend code' needs correction.
Again, not all software development is the same. A QA team in many situations is a team that cannot develop automated testing because they know how to use the software, not develop software. Because they represent the target customer base, not 'more development'. They provide a *distinct* perspective from what those skilled in software development can do for themselves. While automated testing can be done to assure that the various functions execute according to the design intent of the developer, usability may be utter crap and a QA team is the group to call the developers on it.
I have yet to see a shop that does continuous anything with a distinct team responsible for the automated testing. The QA team *is* the development team everywhere I have seen. The unit tests comprising the continuous integration are more often than not a joke.
Just because there are a gobton of 'ideas' that are 'yet another trivial frontend for a database' with fleeting interactions with users that can be stood up in a few minutes to an hour, this does not mean all applications can be reasonably have quality managed in the context of continuous delivery. Continuous Integration is fine and a solid approach that is fairly generally applicable across the board to shield a manual QA effort from asinine stuff, but a manual QA effort is still frequently warranted for complex applications with long term user experience concerns.
It's of limited utility so long as .vbs/.bat/.cmd still can run without such protections in the same context.
And on the 'you have to have admin rights', there is something deeply wrong with the Windows userbase. I made an app for Windows and made it available to some testers and went to see what they did. About 7 out of 10 of the test users right clicked to 'run as administrator' without even *trying* to run it normally. Even after telling them as the developer of the application that it does not need admin rights, 2 of them refused to run it normally, because they didn't believe that it could work without it.
'continuous delievery' is a term with a defined meaning. And releasing phone apps with unwanted UI/functionality in rapid succession is not part of that definition.
It is a natural consequence of a continuous delivery, emphasis on always evolving and changing and that the developer is king and no one can question developer opinion. Devolper decides it should move, it moves. No pesky human testers to stand up and say 'you confused the piss out of us' to make them rethink it. No automatic test is going to capture 'confuse the piss out of the poor non-developer users'.
If you have crashes on those nodes or customer complaints you roll back.
Note that a customer with a choice is likely to just go somewhere else rather than use your software. They'd actually have to care about your success to bother complaining if there is any hint of competition in the market.
The problem is that automated testing is no substitute for a QA team. This is fine for continuous integration, where the output is not considered production ready. A QA team consisting of people just like your real users who are paid to put up with your crap and complain rather than just go on to a competing product. Not people who know the code inside and out and are ready to help rationalize your design choices, but people who will challenge you, and rightfully tell you they don't give a shit that you think it's hard to do it the way that makes sense.
Continuous delivery is impossible to say that QA team still matters, as they have no ability to intervene when you go down the wrong path.
I don't see a reason why that would not work for embeded likewise.
Because 'crashes' and/or 'customer complaints' can mean people die in some of those cases, so saying 'rollback if it didn't work' is too late.
.
Analyst who understands neither software development nor AI proceeds to try to sound insightful about both.
The crux of the problem is that we (in these discussions and the analysts) describe *all* manner of 'software development' as the same thing. Whether it's a desktop application, an embedded microcontroller in industrial equipment, a web application for people to get work done, or a webapp to let people see the latest funny cat video.
Then we start talking past each other, some of us terrified what 'continious delivery' means in the context of software in the microcontroller of a health care device, others thinking about amazon's shopping front and not seeing the big deal.
Also, there's the scope of changes. I know I hear familiy members complaining about various android apps shifting around and basically having to continually relearn stuff. Making small changes that may not even be noticed is one things, continually migrating navigation to a particular feature because you keep having 'better ideas' about what makes sense is maddening.
Of course the business behind it for externalized software development is software as a subscription is continual revenue, even if you don't have any compelling ideas to deliver value to the client that would otherwise make them cough up the money.
Of course a cmd/bat file can merrily do that as a prelude to an evil powershell script, so the execution policy is only annoying to legit users without being a significant problem to those that would use ps1 as an attack vector.
It would be maybe something if ps1 content could execute in some context that cmd/bat files could not (e.g. the way microsoft put activex everywhere), but they know better than to even try that. So they have something that would have mitigated problems they had with ActiveX, but also a reluctance to even risk it anywhere where ActiveX was a unique threat...
I think you'll have to explain why that's a problem...
The powershell signing situation always baffled me.
To run a powershell script, you must sign it. Which is of course terribly inconvenient, but hey, at least it is secure.
Except you can disable the restrictions easily, so easily in fact that a would be attacker need only do one very minor thing prior to their script having to execute for all this to not matter, and that minor thing is readily accessible through a .bat or .cmd script (which I have seen professional software do even, temporarily relax the policy then re-enable when done, without a user having to approve/explicitly do it manually).
It's a way to vigorously say 'we were focused on security' and all the inconvenience for people to feel 'yep they thought about security' and arrive at a completely useless protection against attackers.
Having had a front row seat to one of those, they are afraid they'll look like ignorant idiots if they try to engage to open ended emails to their company. They are afraid of setting the expectation they could help via email, and then get judged poorly when they fail at trying. They might have an incredibly disparate set of products bearing their name.
I don't know them personally, but imagine if you emailed 'help@honeywell.com'. Honeywell has everything from little home space heaters to military UAVs to Airport landing systems. Such a company may be concerned that without some requiring some context, that they'll bumble the reply and it will look poorly.
Of course, a 'nice' thing would be software that analyzes and engages in a 'phone tree' like auto-reply if it can't figure it out. A nicer thing would be a few humans to sort it out.
It could be argued that even those user initiated notifications warrant a way of replying. For example I got an email notification of a password reset on an account that I did *not* ask for. In this case it was encouraged to reply if this was not the case, while also unable to continue without my assenting.
Anytime you receive a message toward one human, it just makes sense for that human to be able to reach back and engage with another human because the automated context may not always be what it seems.
Software can triage email coming in, and failing that, round robin the email to humans who may not know how to answer, but know their own company well enough to quickly bounce to someone who will.
Already email analysis is a fact of life (spam and phishing), having customer relationship management as part of that doesn't seem such a stretch.
So there's a class of companies in that category...
There is another class of company that uses 'no-reply' because they are fixated on a particular engagement model that forces issues into tracket tickets and set of tools to manage them that doesn't know how to deal with email. They don't trust the user to keep an email thread intact to allow someone to follow the history, or they don't have software they trust to translate email thread to a ticketing system.