On the one hand, on balance it's a lot more sane than the xml atrocities of the early 2000s.
On the other hand, the people who overthought things and overengineerd XML making it needlessly complex have been mandating weird stuff in JSON, but they aren't as pervasive as it was with XML's height of craziness.
Of course, it's replaced with another sort of craziness, with REST (a generally good ideal of actually using the HTTP protocol vaguely as intended) people saying "no need to promise day to day compatibility, because hypermedia!"
As a user maintaining internal software, that's.. ok..... Software collections though require copious amount of duct tape and don't quite act the same as when it is *in* the distro (at least when I needed to use httpd from software collections, it was a huge mess).
As a vendor, it's often unacceptable to mandate software collections for your software to work. Hell they hated when I had a dependency in the "optional" channel, forcing me to stay away from even that.
When you 'deprecate' something but not even have the non-deprecated version without resorting to the workaround that is software collections, that is not right.
I'm not sure how they'll do it, at one point last year a RHEL rep was telling me that/usr/bin/python was going to be python3, and I told them they were setting themselves up for a world of hurt from gobs of customer python scripts suddenly breaking in subtle ways, and/usr/bin/python missing completely and only there being python3 would be a clear sign of needing migration.
Sometimes you have things that people have asked for, but you did not make a commitment for. They want it, but they are not *expecting* it per se.
Also there are things where the users are unhappy about something, but unable to conceive of how it could be better and are resigned to think of it as a sad reality and thus are not expecting change for the better.
Also if you are going to cover more breadth of function and take on responsibilities that the users would not have thought of at all.
Contrast with having your product relate to another product and that product *will* release an update that your software cannot work with, that's a hard deadline. Or a customer has said that purchase is contingent upon the function.
For things that would improve your user experience, but are not "deal breakers" I've found it best to not commit a timeframe to the users and instead surprise them, or say it's being worked on but not express when you expect it done. When delivered, it's a very positive impression. When it slips without a promise, it doesn't tend to upset the customer. If you had said it would be ready by a certain time though, they will get much more upset. Of course, this is subjective, you can't just slip such deliverables forever, eventually the user would decide that your project is stagnant or that you never deliver on "we're working on it", so you do have to do enough to show continual progress, but it's a lot more nuanced and subjective than "you will have this thing you don't abosolutely need in precisely 2 weeks time".
I particularly struggle with management on estimates. I insisted that for 70% of the work, we don't need projections, and that allows us to properly focus on the minority of work that has *real* deadlines. Management feels like if you don't know when you'll get to it, and no one is specifically going to be looking for the delivery, why would we do it? So we end up with BS no-one cares stuff effectively blocking sudden and important real requirements because we are flagging stuff as 'need to do in three weeks time because someone demanded a random guess'.
I have said point blank to my management that I don't *want* a team of 50 programmers they 'help' get for me, I want 4 or 5 programmers I actually vet. This makes no sense to them, because more people == better, but in software small teams almost always do better.
In my experience, those who act in accordance to how Agile describes itself, generally do not call themselves Agile, they just aren't interested in the formal labels. They also don't need anyone to tell them common sense about how to be effective, it comes naturally.
Agile in practice is institutionalized self-delusion for managers in dysfunctional organizations to fool themselves into thinking they can be a good organization by waving a magic wand and getting some certification from a consultant.
Sorry, that went out the window when consultants saw money to be made. Processes and tools are big money makers. Telling people "just talk to each other" isn't enough to make a lot of money.
The name would have doomed it, project managers love the buzzword, love self-affirming that they are 'formally' 'Agile', and they also love making things unidirectional. They love using tools instead of interactions, because a tool can allow for measurement, but conversations are so much more subjective.
Never mind that delving deep into the subjective nature of the work in my experience always leads to *much* better work and it being *much* easier, management doesn't have any metrics, so they don't like it.
Add to that knowing *precisely* what people will be doing 6 months from now. Yes I know this is nominally exactly *not* something advocated in the words of Agile, but because so many in management demand it, the consultants have found ways to present epics with stories planned for months as still 'Agile' to collect their check and let the company have warm self-affirmations that they are now 'Agile'.
In addition to metrics, they have the hope that applying project management can magically allow them to use cheap random developers to either accelerate or replace development.
I've seen projects that were surprise successes, largely because a really good and motivated technical team did something unbidden. Then seen such efforts utterly ruined when the business tried to 'help' by putting it under project management and reassigned developers to be 'more effective'.
The reality is that 'Agile' is the latest fad viewed by bad organizations as the silver bullet to fix all their bad behavior. As such it is a very profitable consulting gig, taking money from companies desparate for self-improvement. It's ultimately hollow, the bad orgs are going to be bad orgs, and waving *any* 'methodology' at the same team will deliver pretty much the same bad experience. It's not that 'Agile' is bad, just that there isn't *any* such thing as generic process guidance that can fix a truly dysfunctional team.
Meanwhile, the consultants can keep things going through true Scotsmen fallacy. A team carefully planned every minutia of a two year effort in advance and not deviate contrary to the ostensible tenants of Agile, and they succeed, they truly get Agile even though you might not see it at first. If another company does avoid overthinking too much in advance, think they are adapting to situations as they evolve, but fail, well, they didn't *really* get 'Agile' somehow or another.
-You don't know what you are doing and you are going to be paying *someone* to know what they are doing. Many may believe that such a Linux customer is a unicorn, but I have seen many people relying heavily upon their enterprise vendor. -You need urgent human attention to problems as they arise. Recently I worked with a company that needed to understand the root cause of a kernel panic they were hitting *immediately*, and RedHat was there for that. -To pass the buck when things do go south.
You are correct that from a technical perspective, CentOS is all the capability but none of the hassle. It just doesn't have any of the guaranteed human attention, and that is really what you are paying for. All that said, their entitlement scheme is terribly convoluted and even if I would be willing to pay, it's enough to make me not want to use them.
So in Windows, you are force feed updates whether you like it or not, including functional changes that may or may not be quite ready. Updates are not merely there, you are stuck with them. Generally people welcomed the Windows updates prior to when 10 released, and then microsoft started cramming the most modern thing down every Windows device from 7 and up, and generally ruined trust in updates.
In Android, you frequently don't have a choice to even update, it's nice to at least have the choice.
Currently in the 'Windows updates are annoying' crowd, Android is worse because at least Microsoft does offer security and bugfixes for various updates, though it's an arcane art to *not* be advanced to the latest 6ish-month release.
HSTS means nothing to http (no s) I *suppose* the other headers requesting browser behavior aren't part of ftp and that could matter. If embedded in an http(s) hosted html page,I would have thought that page should have had all those relevant security headers, and those security headers should already be blocking ftp content from loading as part of such pages if configured...
Ok, but it also says mixed content for http, and I would think in principle, http and ftp would be considered equivalent security....
The whole point of urls after all was to include protocols and have flexibility to have fit-for-purpose protocols. Nowadays the only protocol is http, and when it isn't, we must shoehorn it into http. This has been disappointing and pretty senseless (at this point, arbitrary TCP style protocols are possible to implement on top of http and this is somehow considered more sane than just having tcp based protocols.... somehow?)
My disappointment is a bit more academic I suppose, in practice ftp servers are a cesspool of sloppy and lazy admins, even if the protocol itself is theoretically the same, sometimes the practical answer is to consider the wider reality of how that protocol has been implemented and deployed.
Not at all, we invented something called disk encryption
Which I went into, at length. Admittedly, I'm unsure if there is a TPM PCR mutated by the cryptographic hashes of EFI executables, but such a mechanism would allow arbitrary efi to execute, but mutate the PCRs to prevent disk encryption key from being unlocked if altered. In this way, a relatively simple shim.efi (the same sort that enables secureboot without having to get updates signed endlessly) could be responsible for both ensuring PCR validty to get a volume key, and then subsequently verify subsquent content, using vendor-specific verification mechanism.
This would be secure, more accessible, and permit the OS to do a more thorough validation of the platform it is booting on (compared to taking the secureboot flag at face value)
I have used several. If I write a function called copydata that takes two filenames and then does an open on both of them and manually reads from one and writes to another, I have not met an IDE that will say "hmm, the way that function works, you *sure* you shouldn't be using this standard library function?
Sure when you try to make one and shadow another, it will point this out. Completion may complete a function name that you were about to do and give insight. If you however do not get caught by one of those two mechanisms (you function name differs from the standard library), the IDE isn't going to anlyze functions and suggest stdlib alternatives.
Defense for BYOD generally comes down as a business mandate, to avoid the company spending money on devices when the employees can spend their own. Even bad IT would prefer not to permit BYOD, as their jobs are unambiguously easier if they control the devices (even when they do a poor job at it, at least they feel in control).
I don't know how much bad IT can be attributed to IT depts coding in C, I rarely see an IT department do that, good or bad.
Broadly speaking, business leaders are largely unable to discern the difference in effectiveness of half-assed IT and good IT. Except for two facets: -You become the next equifax -Good IT costs more
Of course, even if they want good IT, they can't tell the difference, so they my try to invest to get "good IT" and still get bad IT and have expectations calibrated that there is no good or bad IT, only cheap and expensive.
One sign of bad IT is your employees complaining about how bad the systems are. From a business perspective the answer is to tell your employees to suck it up, perceive them as whiners. They can't imagine better. The tools selected come from big reputable companies with reassuring salespeople talking it up and how it has improved other customers, while the pitiable users are comparatively less well equipped to precisely explain how or why the system sucks. In the meantime, often this phenomenon is offset by the users by "shadow IT", peer support to give each other what they need to get their jobs, without telling official IT about it (because the relationship between IT and people gets adversarial). This is a strong indication IT has picked the wrong tools for the job, but it also tends to create invisible business critical systems with 'admin' as the password.
Note that sometimes it's what bad IT does to otherwise well made software, imposing maddening workflows that make no sense on software that was designed for a sane world.
In sceinftific computing, your developers are largely not programmers, but scientists. This is why Fortran has enjoyed more relevance in that field than everywhere else, it maps more closely to how they express and learn math.
It is also the case that when it comes to intensive operations, they are generally merely supervising standard modules. specifically, python scripts can supervise numpy code, and that implementation is what matters not the text the scientist is typing.
Essentially, they need a "glue" lanuage, they don't need the glue to be fast, they just need the pieces to be fast. They need languages that relate to their professional experience and/or a language that won't intimidate them. IPython and numpy are very prominent reasons why python has been relatively popular in scientific computing.
Certainly, scientific computing cares a lot about c and python, but they care too about python.
Of course, only if you know where to look. If you don't know a standard library function exists, you may waste time rolling your own, and probably not as good as the language runtime provides. No IDE is going to look at your function and recognize there's a standard library equivalent.
I think the issue would be if you are very familiar with one particularly rich standard library (e.g. Java) you know there's something to look for in another language.
The things that can be missed are obscure realities of a language that tend to also be missed by veterans. In my experience, for example, even long time python developers are frequently unaware of memory views, bytearrays, and such that can speed up a large class of functions dramatically or make things a lot easier in general (I too often see a binary string converted to a list through list comprehension and ord(), as the usual go to for people unaware of bytearray).
I will say I'd rather deal with the ramp up of a programmer as they fail to be aware of a standard library feature than someone who has more time in with the language I want but seems to lack good problem solving skills. Particularly with code reviews, you can recognize patterns that are bad.
Of course, if you have a blind leading the blind scenario, that can't be good. I once sat in with a java team and a developer with over a decade of java experience was asking me if I had any thoughts on why file copies in his code were slow. I immediately recognized that he wrote a file copy routine from scratch and found out he was completely unaware that java had a standard file copy routine. No one on his team even thought about that possibly existing. Knowing that was their most senior and respected developer, it suddenly explained to me a lot of their quality problems.
All this talk is acting like C's general behavior is broadly a security problem and you can't have a language that empowers the user and be secure, but we can get more specific.
The biggest one is no innate range checking. Understandable, as range checking in the optimal case would at least require a handful more operations per array access, and particularly decades ago that was not affordable. In terms of capability, this isn't a capability anyone needs. One could argue that it robs users of the ability to deliver the fastest possible array indexing when they know it to be safe, though I wager that compiled languages at least have a shot of detecting most of the truly safe snippets and skipping range checking for static sized lists indexed only by constant numbers that can be compile-time checked.
Another is that the programmer must manually assure that strings have a null byte at the end. Again, being able to have a string and then not put a null byte in it is not something that has any practical application whatsoever.
Then there are various standard library functions that must be carefully used or not used at all.
Essentially, none of this seems to be issues of empowerment, they just demand more of the programmer to roll their own methodology to prevent common bad scenarios. There isn't any empowerment associated with being able to write the 15th byte of a 10 byte array.
Slashdot Mirror
JSON is interesting.
On the one hand, on balance it's a lot more sane than the xml atrocities of the early 2000s.
On the other hand, the people who overthought things and overengineerd XML making it needlessly complex have been mandating weird stuff in JSON, but they aren't as pervasive as it was with XML's height of craziness.
Of course, it's replaced with another sort of craziness, with REST (a generally good ideal of actually using the HTTP protocol vaguely as intended) people saying "no need to promise day to day compatibility, because hypermedia!"
As a user maintaining internal software, that's.. ok..... Software collections though require copious amount of duct tape and don't quite act the same as when it is *in* the distro (at least when I needed to use httpd from software collections, it was a huge mess).
As a vendor, it's often unacceptable to mandate software collections for your software to work. Hell they hated when I had a dependency in the "optional" channel, forcing me to stay away from even that.
When you 'deprecate' something but not even have the non-deprecated version without resorting to the workaround that is software collections, that is not right.
I'm not sure how they'll do it, at one point last year a RHEL rep was telling me that /usr/bin/python was going to be python3, and I told them they were setting themselves up for a world of hurt from gobs of customer python scripts suddenly breaking in subtle ways, and /usr/bin/python missing completely and only there being python3 would be a clear sign of needing migration.
Sometimes you have things that people have asked for, but you did not make a commitment for. They want it, but they are not *expecting* it per se.
Also there are things where the users are unhappy about something, but unable to conceive of how it could be better and are resigned to think of it as a sad reality and thus are not expecting change for the better.
Also if you are going to cover more breadth of function and take on responsibilities that the users would not have thought of at all.
Contrast with having your product relate to another product and that product *will* release an update that your software cannot work with, that's a hard deadline. Or a customer has said that purchase is contingent upon the function.
For things that would improve your user experience, but are not "deal breakers" I've found it best to not commit a timeframe to the users and instead surprise them, or say it's being worked on but not express when you expect it done. When delivered, it's a very positive impression. When it slips without a promise, it doesn't tend to upset the customer. If you had said it would be ready by a certain time though, they will get much more upset. Of course, this is subjective, you can't just slip such deliverables forever, eventually the user would decide that your project is stagnant or that you never deliver on "we're working on it", so you do have to do enough to show continual progress, but it's a lot more nuanced and subjective than "you will have this thing you don't abosolutely need in precisely 2 weeks time".
I particularly struggle with management on estimates. I insisted that for 70% of the work, we don't need projections, and that allows us to properly focus on the minority of work that has *real* deadlines. Management feels like if you don't know when you'll get to it, and no one is specifically going to be looking for the delivery, why would we do it? So we end up with BS no-one cares stuff effectively blocking sudden and important real requirements because we are flagging stuff as 'need to do in three weeks time because someone demanded a random guess'.
I have said point blank to my management that I don't *want* a team of 50 programmers they 'help' get for me, I want 4 or 5 programmers I actually vet. This makes no sense to them, because more people == better, but in software small teams almost always do better.
In my experience, those who act in accordance to how Agile describes itself, generally do not call themselves Agile, they just aren't interested in the formal labels. They also don't need anyone to tell them common sense about how to be effective, it comes naturally.
Agile in practice is institutionalized self-delusion for managers in dysfunctional organizations to fool themselves into thinking they can be a good organization by waving a magic wand and getting some certification from a consultant.
Sorry, that went out the window when consultants saw money to be made. Processes and tools are big money makers. Telling people "just talk to each other" isn't enough to make a lot of money.
The name would have doomed it, project managers love the buzzword, love self-affirming that they are 'formally' 'Agile', and they also love making things unidirectional. They love using tools instead of interactions, because a tool can allow for measurement, but conversations are so much more subjective.
Never mind that delving deep into the subjective nature of the work in my experience always leads to *much* better work and it being *much* easier, management doesn't have any metrics, so they don't like it.
Add to that knowing *precisely* what people will be doing 6 months from now. Yes I know this is nominally exactly *not* something advocated in the words of Agile, but because so many in management demand it, the consultants have found ways to present epics with stories planned for months as still 'Agile' to collect their check and let the company have warm self-affirmations that they are now 'Agile'.
In addition to metrics, they have the hope that applying project management can magically allow them to use cheap random developers to either accelerate or replace development.
I've seen projects that were surprise successes, largely because a really good and motivated technical team did something unbidden. Then seen such efforts utterly ruined when the business tried to 'help' by putting it under project management and reassigned developers to be 'more effective'.
The reality is that 'Agile' is the latest fad viewed by bad organizations as the silver bullet to fix all their bad behavior. As such it is a very profitable consulting gig, taking money from companies desparate for self-improvement. It's ultimately hollow, the bad orgs are going to be bad orgs, and waving *any* 'methodology' at the same team will deliver pretty much the same bad experience. It's not that 'Agile' is bad, just that there isn't *any* such thing as generic process guidance that can fix a truly dysfunctional team.
Meanwhile, the consultants can keep things going through true Scotsmen fallacy. A team carefully planned every minutia of a two year effort in advance and not deviate contrary to the ostensible tenants of Agile, and they succeed, they truly get Agile even though you might not see it at first. If another company does avoid overthinking too much in advance, think they are adapting to situations as they evolve, but fail, well, they didn't *really* get 'Agile' somehow or another.
There are a few reasons to buy RHEL:
-You don't know what you are doing and you are going to be paying *someone* to know what they are doing. Many may believe that such a Linux customer is a unicorn, but I have seen many people relying heavily upon their enterprise vendor.
-You need urgent human attention to problems as they arise. Recently I worked with a company that needed to understand the root cause of a kernel panic they were hitting *immediately*, and RedHat was there for that.
-To pass the buck when things do go south.
You are correct that from a technical perspective, CentOS is all the capability but none of the hassle. It just doesn't have any of the guaranteed human attention, and that is really what you are paying for. All that said, their entitlement scheme is terribly convoluted and even if I would be willing to pay, it's enough to make me not want to use them.
Particularly since RHEL 7 shipped with *only* 2.
Generally, you'd have an overlap of both.
So in Windows, you are force feed updates whether you like it or not, including functional changes that may or may not be quite ready. Updates are not merely there, you are stuck with them. Generally people welcomed the Windows updates prior to when 10 released, and then microsoft started cramming the most modern thing down every Windows device from 7 and up, and generally ruined trust in updates.
In Android, you frequently don't have a choice to even update, it's nice to at least have the choice.
Currently in the 'Windows updates are annoying' crowd, Android is worse because at least Microsoft does offer security and bugfixes for various updates, though it's an arcane art to *not* be advanced to the latest 6ish-month release.
HSTS means nothing to http (no s)
I *suppose* the other headers requesting browser behavior aren't part of ftp and that could matter. If embedded in an http(s) hosted html page,I would have thought that page should have had all those relevant security headers, and those security headers should already be blocking ftp content from loading as part of such pages if configured...
Ok, but it also says mixed content for http, and I would think in principle, http and ftp would be considered equivalent security....
The whole point of urls after all was to include protocols and have flexibility to have fit-for-purpose protocols. Nowadays the only protocol is http, and when it isn't, we must shoehorn it into http. This has been disappointing and pretty senseless (at this point, arbitrary TCP style protocols are possible to implement on top of http and this is somehow considered more sane than just having tcp based protocols.... somehow?)
My disappointment is a bit more academic I suppose, in practice ftp servers are a cesspool of sloppy and lazy admins, even if the protocol itself is theoretically the same, sometimes the practical answer is to consider the wider reality of how that protocol has been implemented and deployed.
I'm not sure I grasp the logic of treating ftp distinct from http (no s) from a security perspective?
Not at all, we invented something called disk encryption
Which I went into, at length. Admittedly, I'm unsure if there is a TPM PCR mutated by the cryptographic hashes of EFI executables, but such a mechanism would allow arbitrary efi to execute, but mutate the PCRs to prevent disk encryption key from being unlocked if altered. In this way, a relatively simple shim.efi (the same sort that enables secureboot without having to get updates signed endlessly) could be responsible for both ensuring PCR validty to get a volume key, and then subsequently verify subsquent content, using vendor-specific verification mechanism.
This would be secure, more accessible, and permit the OS to do a more thorough validation of the platform it is booting on (compared to taking the secureboot flag at face value)
I have used several. If I write a function called copydata that takes two filenames and then does an open on both of them and manually reads from one and writes to another, I have not met an IDE that will say "hmm, the way that function works, you *sure* you shouldn't be using this standard library function?
Sure when you try to make one and shadow another, it will point this out. Completion may complete a function name that you were about to do and give insight. If you however do not get caught by one of those two mechanisms (you function name differs from the standard library), the IDE isn't going to anlyze functions and suggest stdlib alternatives.
Defense for BYOD generally comes down as a business mandate, to avoid the company spending money on devices when the employees can spend their own. Even bad IT would prefer not to permit BYOD, as their jobs are unambiguously easier if they control the devices (even when they do a poor job at it, at least they feel in control).
I don't know how much bad IT can be attributed to IT depts coding in C, I rarely see an IT department do that, good or bad.
Broadly speaking, business leaders are largely unable to discern the difference in effectiveness of half-assed IT and good IT. Except for two facets:
-You become the next equifax
-Good IT costs more
Of course, even if they want good IT, they can't tell the difference, so they my try to invest to get "good IT" and still get bad IT and have expectations calibrated that there is no good or bad IT, only cheap and expensive.
One sign of bad IT is your employees complaining about how bad the systems are. From a business perspective the answer is to tell your employees to suck it up, perceive them as whiners. They can't imagine better. The tools selected come from big reputable companies with reassuring salespeople talking it up and how it has improved other customers, while the pitiable users are comparatively less well equipped to precisely explain how or why the system sucks. In the meantime, often this phenomenon is offset by the users by "shadow IT", peer support to give each other what they need to get their jobs, without telling official IT about it (because the relationship between IT and people gets adversarial). This is a strong indication IT has picked the wrong tools for the job, but it also tends to create invisible business critical systems with 'admin' as the password.
Note that sometimes it's what bad IT does to otherwise well made software, imposing maddening workflows that make no sense on software that was designed for a sane world.
In sceinftific computing, your developers are largely not programmers, but scientists. This is why Fortran has enjoyed more relevance in that field than everywhere else, it maps more closely to how they express and learn math.
It is also the case that when it comes to intensive operations, they are generally merely supervising standard modules. specifically, python scripts can supervise numpy code, and that implementation is what matters not the text the scientist is typing.
Essentially, they need a "glue" lanuage, they don't need the glue to be fast, they just need the pieces to be fast. They need languages that relate to their professional experience and/or a language that won't intimidate them. IPython and numpy are very prominent reasons why python has been relatively popular in scientific computing.
Certainly, scientific computing cares a lot about c and python, but they care too about python.
Of course, only if you know where to look. If you don't know a standard library function exists, you may waste time rolling your own, and probably not as good as the language runtime provides. No IDE is going to look at your function and recognize there's a standard library equivalent.
I think the issue would be if you are very familiar with one particularly rich standard library (e.g. Java) you know there's something to look for in another language.
The things that can be missed are obscure realities of a language that tend to also be missed by veterans. In my experience, for example, even long time python developers are frequently unaware of memory views, bytearrays, and such that can speed up a large class of functions dramatically or make things a lot easier in general (I too often see a binary string converted to a list through list comprehension and ord(), as the usual go to for people unaware of bytearray).
I will say I'd rather deal with the ramp up of a programmer as they fail to be aware of a standard library feature than someone who has more time in with the language I want but seems to lack good problem solving skills. Particularly with code reviews, you can recognize patterns that are bad.
Of course, if you have a blind leading the blind scenario, that can't be good. I once sat in with a java team and a developer with over a decade of java experience was asking me if I had any thoughts on why file copies in his code were slow. I immediately recognized that he wrote a file copy routine from scratch and found out he was completely unaware that java had a standard file copy routine. No one on his team even thought about that possibly existing. Knowing that was their most senior and respected developer, it suddenly explained to me a lot of their quality problems.
All this talk is acting like C's general behavior is broadly a security problem and you can't have a language that empowers the user and be secure, but we can get more specific.
The biggest one is no innate range checking. Understandable, as range checking in the optimal case would at least require a handful more operations per array access, and particularly decades ago that was not affordable. In terms of capability, this isn't a capability anyone needs. One could argue that it robs users of the ability to deliver the fastest possible array indexing when they know it to be safe, though I wager that compiled languages at least have a shot of detecting most of the truly safe snippets and skipping range checking for static sized lists indexed only by constant numbers that can be compile-time checked.
Another is that the programmer must manually assure that strings have a null byte at the end. Again, being able to have a string and then not put a null byte in it is not something that has any practical application whatsoever.
Then there are various standard library functions that must be carefully used or not used at all.
Essentially, none of this seems to be issues of empowerment, they just demand more of the programmer to roll their own methodology to prevent common bad scenarios. There isn't any empowerment associated with being able to write the 15th byte of a 10 byte array.