Software is very much like buildings and road works.
Let's look at the brick-and-mortar world first. We have both architects and engineers. Sometimes there's a separate landscape architect or drainage engineer. We have construction contractors who specialize in high-rise buildings, in stadiums and convention halls, in bridges, or in roads. We have subcontractors for structure, electrical, plumbing, painting, flooring, and heating/air conditioning. Sometimes there are individual contractors for windows and doors, sometimes for data wiring vs. mains, sometimes for landscaping, and sometimes for signage. Then a lot of office furniture, factory equipment, kitchen appliances like walk-in freezers, and such have their own contractors come in.
Then there's the individual family home. There are engineered parts, but the building is almost never engineered. It may not be architected. It's built by a general contractor, sometimes with few to no subcontractors. Oh, there may need to be a master plumber and a master electrician at the company, but they go out to each house a couple of times to supervise the final attachment of things laborers and plumbing/electrical apprentices put in place.
Sometimes a homeowner just wants to pour a new parking pad beside the garage for his boat. So a couple of buddies dig it out, they put up forms, and they haul in some gravel for a base and rent a cement mixer.
Software's much like that. We have big projects that are more or less fully engineered. Sometimes you're building life support. Sometimes you're building a web site to advertise an ice cream truck's schedule and flavors. Often you build something in between life support and the electronic version of a paper flyer (which if you're okay with being static doesn't need programming at all). There are reliability concerns and cost concerns. The thing to do is to get it as reliable as it needs to be within budget. Your little sister's blog doesn't need to fail as gracefully as nuclear power plant controls. Regardless of how important she feels posting about her day is, a town isn't going to be irradiated for three centuries if it's down today.
It really depends on what type of server we're talking about. Is it a front-end web server? Is it a middleware application server? Is it a database server for small to medium databases? Is it a big DB cluster? Is it a media or document storage system? Is it a hypervisor on a hardware node offering shards of its resources to VMs? These have different storage and processing needs.
In the short term, there are a few solutions for the OS and applications. Many applications will keep as much in memory as possible already. Most OSes support RAM disks, so you could put a very fast virtual disk into your main RAM if you have 4 or 6 TiB of RAM and an application absolutely needs to think it's writing to disk. Also, I doubt segmented storage is going away entirely. You'll still have disks, SSDs, or separate blocks of this stuff available for truly cold storage if you need it. You just won't use them very much compared to today.
This is getting to be a heady argument. Why don't you two park it over there and find some way to re-float this issue? You're both coiled and it's creating a giant resistance.
Sound engineering principles follow improvements in materials, logistical support, and manufacturing techniques. If someone finds a lot of material around a dim star near a much brighter star with little material and they have the means to transport it from one system to the other, it's a possibility. Perhaps they have something like a working Alcubierre drive that allows rapid transport among nearby compact solar systems. Maybe they're collecting interstellar dust and debris and moving it inward into systems.
Also, perhaps this alien engineering includes fabricating matter from energy. Perhaps they have enough energy, physics, and engineering to start harvesting enough energy to create much of the matter they need in a solar system that has a high-output star, in order to capture yet more energy.
All of these things are hinted at by our current understanding of physics. If a society could master them, it may be a geometric improvement in capabilities like the computer or the internal combustion engine rather than taking a species just along a slightly faster linear path.
The important thing about the railgun, though, is that it's a big conductive chunk of dumb metal. It's a direct-fire or ballistic weapon, not a guided one. We already have supersonic missiles. Missiles and rockets cost a lot of money to build and then are destroyed, but are often launched from relatively inexpensive platforms. Railguns put the expense in the maintainable, reusable launcher and use cheap ammunition that causes plenty of damage from kinetic impact.
You're assuming a group would endeavor to build a totally enclosed sphere with the resources of only a single small system. That's a reasonable assumption, but perhaps they built only scaffolding and pods, with each pod having its own solar collectors nearby. Maybe they're bringing in material from several systems. Maybe it doesn't need to be habitable (at least not yet) because it's built by an advance team of robotic probes.
Any scenario that isn't an as yet unexplained natural phenomenon is already violating Occam's Razor. The simplest explanation is most likely to be true. Once we're not worried about the most probable, then anything possible is within the realm of discussion.
Full auto weapons or selective fire ones in full auto mode are often used specifically for suppressive fire. Keep the enemy down with volume of fire while your guys with more accurate weapons maneuver. Then someone with a more accurate weapon can take people out. Of course, if you're firing at a hostile crowd sometimes volume of fire is better than hitting one target precisely for that.
You can't add much to a Mach 7 tungsten bolt that already caught fire from friction with the air by adding explosive rocket fuel to it. Well, maybe if you intend to fire it from space you could since there's no atmosphere, but the Navy is still mainly water-based.
Maybe it's a super advanced Tea Party isolationist culture that doesn't want outside light. >_>
If you build it sturdy enough at the goldilocks zone, you could not just harvest light for electrical energy, but make much of the interior surface habitable for plant life. Also, perhaps a civilization wouldn't do this to their own star, but to a nearby star with no habitable natural bodies around it. Or they could use their entire planetary mass to build the sphere, and live in pods within the sphere.
Forget the interior surface spinning for false gravity, put structures on pylons inside it, with the floors perpendicular to the spin.
Perhaps if some civilization did do something like this, there wouldn't even be life in the solar system as it was done. It might all be robotic probes from the next system over.
As long as it's all speculation, we can speculate all sorts of things.
You're very close to how I'd word it with babies. See, if you want one baby you wait 9 months. If you want 5 babies and you have one mother, you wait 55 or 60 months. If you want five babies in 9 months, you can totally have five mothers. You can't get one full-term baby any faster than 9 months by adding mothers. DevOps doesn't solve the one baby problem any faster nor the five babies by one mother problem any faster. It can solve the five babies problem if you're okay with the babies having different mothers (team leads or sub-project managers) and different DNA (team implementation styles). If the other parent (the overall project lead or the solution architect) is the same, the five babies may learn to live together as a family, although there's the possibility they won't.
This is my point. It works very well for a well-defined, well-understood, practically standardized stack to be used to write a new application. That's not the same thing as breaking new ground on a project without all that supporting code and voluminous standards documents already helping you out. The Mythical Man Month hasn't been disproven at all. It's just that in some areas it's possible to change the scope of the project. Smaller projects don't take as long.
What has Obama done about it in seven years? Well, he has the SEC forcing health tests on the banks after the collapse happened, but would he have foreseen them any better than Bush?
It's on Clinton and the Republican Congresscritters who wrote the bill.
You see, despite people calling the President the Suggester in Chief, it's not the White House that drafts most legislation. These days it's not even the legislature that drafts most legislation. Think tanks, corporations, think tanks hired by corporations, nonprofits, nonprofits who are actually industry organizations for corporations, lobbyists, and other special interest groups write "model legislation". Then legislators at the state and federal level introduce it with minor changes (usually made by their staff) to committee, who then pass whatever the ruling party on the committee wants to the floor, where there's a vote on whether or not to allow the governor or President to consider signing it.
When have Bush or Obama either one been presented a bill to sign that reverses what Clinton signed?
The thing is, many of these split points are becoming well-defined. Authentication? Just use OpenID Connect. Federated memory cache? Just use memcached. Need a database? Use an ORM that will speak to anything through JDBC, ODBC, PDO, or DBI and hides all the intricacies, then let your DevOps folks and DBAs handle those stock apps as infrastructure. Let the developers focus on the business value.
This works quite well when you're developing yet another web app. It's not the same as developing a new mainframe and its OS that just happens to need to be backwards compatible with two previous generations of mainframes from an application level and offer new features like VMs, virtual I/O, etc. like the 360.
The lesson here isn't that you throw five times as many people at a project. The whole idea of microservices is they are small, interchangeable projects. If you split one big project into five smaller projects, you can have a small team do each project.
This doesn't disprove anything about the Mythical Man-Month. It reinforces it. If you have multiple small, well-defined projects rather than one big, all-encompassing centralized project you can get the work done faster. If you want it all tightly integrated into a project the size of the 360, you need to wait.
You mean by repealing several laws about banks, insurance companies, and investment companies not intermingling and risking the entire banking sector? You mean signing what was basically the repeal of the Glass-Steagall Act of 1933 and the Bank Holding Company Act of 1956? You mean signing the Financial Services Modernization Act of 1999? You mean stating publicly that protections enacted during the Great Depression to keep the financial system from collapsing again were outdated and he was happy to reach across party lines and sign Lindsey Graham's bill?
Oh, that was Bill Clinton. But thanks for playing.
Exactly. More regulations born from our bought-and-paid corporate subsidiary government just stack the regulations in favor of the companies hiring the Congresscritters.
What we need is to get corporate money out of politics. The only corporate money to be handled by anyone in the government should be taxes, fines, and contracts to do things for the people. Less regulation helps the corporations. More regulation helps the corporations even more, because it favors the entrenched ones (taxi companies over Uber, cable TV monopolies over Netflix, Clearchannel over Spotify) over the ones doing the business of capitalism -- selling new, improved products that would compete better if given the chance.
You can't see the whole image if you have an 4k image on a 4k screen and zoom in. You very seriously can't see all the data from an 8k image on a 4k screen. In graphic arts, a person might be making content for a 30-foot tall video billboard. A doctor might want better resolution of a full MRI, and then zoom in even finer. There's no dichotomy here. You aren't going to lose zooming.
Real-world use for lots of people includes looking long and hard at still images. Graphic artists, medical imaging specialists, photographers, archivists, and more. Not everyone needs the highest end for their everyday use. That's okay. Not all of us drive an Indy car or fly from city to city in an F16 either.
Software is very much like buildings and road works.
Let's look at the brick-and-mortar world first. We have both architects and engineers. Sometimes there's a separate landscape architect or drainage engineer. We have construction contractors who specialize in high-rise buildings, in stadiums and convention halls, in bridges, or in roads. We have subcontractors for structure, electrical, plumbing, painting, flooring, and heating/air conditioning. Sometimes there are individual contractors for windows and doors, sometimes for data wiring vs. mains, sometimes for landscaping, and sometimes for signage. Then a lot of office furniture, factory equipment, kitchen appliances like walk-in freezers, and such have their own contractors come in.
Then there's the individual family home. There are engineered parts, but the building is almost never engineered. It may not be architected. It's built by a general contractor, sometimes with few to no subcontractors. Oh, there may need to be a master plumber and a master electrician at the company, but they go out to each house a couple of times to supervise the final attachment of things laborers and plumbing/electrical apprentices put in place.
Sometimes a homeowner just wants to pour a new parking pad beside the garage for his boat. So a couple of buddies dig it out, they put up forms, and they haul in some gravel for a base and rent a cement mixer.
Software's much like that. We have big projects that are more or less fully engineered. Sometimes you're building life support. Sometimes you're building a web site to advertise an ice cream truck's schedule and flavors. Often you build something in between life support and the electronic version of a paper flyer (which if you're okay with being static doesn't need programming at all). There are reliability concerns and cost concerns. The thing to do is to get it as reliable as it needs to be within budget. Your little sister's blog doesn't need to fail as gracefully as nuclear power plant controls. Regardless of how important she feels posting about her day is, a town isn't going to be irradiated for three centuries if it's down today.
It really depends on what type of server we're talking about. Is it a front-end web server? Is it a middleware application server? Is it a database server for small to medium databases? Is it a big DB cluster? Is it a media or document storage system? Is it a hypervisor on a hardware node offering shards of its resources to VMs? These have different storage and processing needs.
In the short term, there are a few solutions for the OS and applications. Many applications will keep as much in memory as possible already. Most OSes support RAM disks, so you could put a very fast virtual disk into your main RAM if you have 4 or 6 TiB of RAM and an application absolutely needs to think it's writing to disk. Also, I doubt segmented storage is going away entirely. You'll still have disks, SSDs, or separate blocks of this stuff available for truly cold storage if you need it. You just won't use them very much compared to today.
This is getting to be a heady argument. Why don't you two park it over there and find some way to re-float this issue? You're both coiled and it's creating a giant resistance.
Is Apple finally a large enough company for antitrust regulators to be concerned about illegal product tying?
Sound engineering principles follow improvements in materials, logistical support, and manufacturing techniques. If someone finds a lot of material around a dim star near a much brighter star with little material and they have the means to transport it from one system to the other, it's a possibility. Perhaps they have something like a working Alcubierre drive that allows rapid transport among nearby compact solar systems. Maybe they're collecting interstellar dust and debris and moving it inward into systems.
Also, perhaps this alien engineering includes fabricating matter from energy. Perhaps they have enough energy, physics, and engineering to start harvesting enough energy to create much of the matter they need in a solar system that has a high-output star, in order to capture yet more energy.
All of these things are hinted at by our current understanding of physics. If a society could master them, it may be a geometric improvement in capabilities like the computer or the internal combustion engine rather than taking a species just along a slightly faster linear path.
The important thing about the railgun, though, is that it's a big conductive chunk of dumb metal. It's a direct-fire or ballistic weapon, not a guided one. We already have supersonic missiles. Missiles and rockets cost a lot of money to build and then are destroyed, but are often launched from relatively inexpensive platforms. Railguns put the expense in the maintainable, reusable launcher and use cheap ammunition that causes plenty of damage from kinetic impact.
You're assuming a group would endeavor to build a totally enclosed sphere with the resources of only a single small system. That's a reasonable assumption, but perhaps they built only scaffolding and pods, with each pod having its own solar collectors nearby. Maybe they're bringing in material from several systems. Maybe it doesn't need to be habitable (at least not yet) because it's built by an advance team of robotic probes.
Any scenario that isn't an as yet unexplained natural phenomenon is already violating Occam's Razor. The simplest explanation is most likely to be true. Once we're not worried about the most probable, then anything possible is within the realm of discussion.
Full auto weapons or selective fire ones in full auto mode are often used specifically for suppressive fire. Keep the enemy down with volume of fire while your guys with more accurate weapons maneuver. Then someone with a more accurate weapon can take people out. Of course, if you're firing at a hostile crowd sometimes volume of fire is better than hitting one target precisely for that.
You can't add much to a Mach 7 tungsten bolt that already caught fire from friction with the air by adding explosive rocket fuel to it. Well, maybe if you intend to fire it from space you could since there's no atmosphere, but the Navy is still mainly water-based.
Maybe it's a super advanced Tea Party isolationist culture that doesn't want outside light. >_>
If you build it sturdy enough at the goldilocks zone, you could not just harvest light for electrical energy, but make much of the interior surface habitable for plant life. Also, perhaps a civilization wouldn't do this to their own star, but to a nearby star with no habitable natural bodies around it. Or they could use their entire planetary mass to build the sphere, and live in pods within the sphere.
Forget the interior surface spinning for false gravity, put structures on pylons inside it, with the floors perpendicular to the spin.
Perhaps if some civilization did do something like this, there wouldn't even be life in the solar system as it was done. It might all be robotic probes from the next system over.
As long as it's all speculation, we can speculate all sorts of things.
If built large enough, the sphere could be outside your planet's orbit.
And the foot and inch in terms of meters... so...
This is why Perl6 is not Perl5.
You're very close to how I'd word it with babies. See, if you want one baby you wait 9 months. If you want 5 babies and you have one mother, you wait 55 or 60 months. If you want five babies in 9 months, you can totally have five mothers. You can't get one full-term baby any faster than 9 months by adding mothers. DevOps doesn't solve the one baby problem any faster nor the five babies by one mother problem any faster. It can solve the five babies problem if you're okay with the babies having different mothers (team leads or sub-project managers) and different DNA (team implementation styles). If the other parent (the overall project lead or the solution architect) is the same, the five babies may learn to live together as a family, although there's the possibility they won't.
This is my point. It works very well for a well-defined, well-understood, practically standardized stack to be used to write a new application. That's not the same thing as breaking new ground on a project without all that supporting code and voluminous standards documents already helping you out. The Mythical Man Month hasn't been disproven at all. It's just that in some areas it's possible to change the scope of the project. Smaller projects don't take as long.
What has Obama done about it in seven years? Well, he has the SEC forcing health tests on the banks after the collapse happened, but would he have foreseen them any better than Bush?
It's on Clinton and the Republican Congresscritters who wrote the bill.
You see, despite people calling the President the Suggester in Chief, it's not the White House that drafts most legislation. These days it's not even the legislature that drafts most legislation. Think tanks, corporations, think tanks hired by corporations, nonprofits, nonprofits who are actually industry organizations for corporations, lobbyists, and other special interest groups write "model legislation". Then legislators at the state and federal level introduce it with minor changes (usually made by their staff) to committee, who then pass whatever the ruling party on the committee wants to the floor, where there's a vote on whether or not to allow the governor or President to consider signing it.
When have Bush or Obama either one been presented a bill to sign that reverses what Clinton signed?
The thing is, many of these split points are becoming well-defined. Authentication? Just use OpenID Connect. Federated memory cache? Just use memcached. Need a database? Use an ORM that will speak to anything through JDBC, ODBC, PDO, or DBI and hides all the intricacies, then let your DevOps folks and DBAs handle those stock apps as infrastructure. Let the developers focus on the business value.
This works quite well when you're developing yet another web app. It's not the same as developing a new mainframe and its OS that just happens to need to be backwards compatible with two previous generations of mainframes from an application level and offer new features like VMs, virtual I/O, etc. like the 360.
The lesson here isn't that you throw five times as many people at a project. The whole idea of microservices is they are small, interchangeable projects. If you split one big project into five smaller projects, you can have a small team do each project.
This doesn't disprove anything about the Mythical Man-Month. It reinforces it. If you have multiple small, well-defined projects rather than one big, all-encompassing centralized project you can get the work done faster. If you want it all tightly integrated into a project the size of the 360, you need to wait.
It was Clinton who signed the repeal of the Glass-Steagall Act of 1999 and the Bank Holding Company Act of 1956.
You mean by repealing several laws about banks, insurance companies, and investment companies not intermingling and risking the entire banking sector? You mean signing what was basically the repeal of the Glass-Steagall Act of 1933 and the Bank Holding Company Act of 1956? You mean signing the Financial Services Modernization Act of 1999? You mean stating publicly that protections enacted during the Great Depression to keep the financial system from collapsing again were outdated and he was happy to reach across party lines and sign Lindsey Graham's bill?
Oh, that was Bill Clinton. But thanks for playing.
Exactly. More regulations born from our bought-and-paid corporate subsidiary government just stack the regulations in favor of the companies hiring the Congresscritters.
What we need is to get corporate money out of politics. The only corporate money to be handled by anyone in the government should be taxes, fines, and contracts to do things for the people. Less regulation helps the corporations. More regulation helps the corporations even more, because it favors the entrenched ones (taxi companies over Uber, cable TV monopolies over Netflix, Clearchannel over Spotify) over the ones doing the business of capitalism -- selling new, improved products that would compete better if given the chance.
You can't see the whole image if you have an 4k image on a 4k screen and zoom in. You very seriously can't see all the data from an 8k image on a 4k screen. In graphic arts, a person might be making content for a 30-foot tall video billboard. A doctor might want better resolution of a full MRI, and then zoom in even finer. There's no dichotomy here. You aren't going to lose zooming.
Real-world use for lots of people includes looking long and hard at still images. Graphic artists, medical imaging specialists, photographers, archivists, and more. Not everyone needs the highest end for their everyday use. That's okay. Not all of us drive an Indy car or fly from city to city in an F16 either.
In Japan "BS" referring to TV means broadcast satellite, as opposed to broadcast from terrestrial towers.
It's almost as if these children are able to prioritize what they eat and adjust when the dishes offered change. /s