I went through the old 41cx, then a 48sx, and now a 49g. I actually like the 49g. It's much faster, can emulate the 48 key patterns, and with good ol' Kermit, I've had no trouble loading firmware and software (with a slight custom cable) from my iBook.
It's got a whack o' RAM, and some decent dev capabilities of course, and a fair bit of in-memory libraries. Add to that the quite useful symbolic calculus that actually doesn't do a number of bizarre, useless Laplace transforms to get a solution, and it was a good upgrade. The ol' 48 got ripped off.
I'm with you on the RPN though. Once you get used to it, it's faster than my old TI-66 with all those brackets.
Duh. The wires are still into your house. They don't disconnect you from local service and rip out the lines from your building. In fact, it is still possible that the line has basic 911 service on it as mandated in the telco regulations for minimum service level. That might not be the case, but at the very least, the "dry copper" is still present. DSL is still able to be provided with a quick bix and interconnect at the CO.
You should not, as the poster pointed out, require a local phone service. Cell phones work quite well that way. The result was derived by knowing how the service is provisioned.
The Planetary Society here has been developing a working solar sail for a number of years now, and it into the final testing preflights for a launch hopefully later this year.
They also have a good overview of solar sailing on the project page here.
Re:oh come on.... download the files first.
on
Preview of Java 1.5
·
· Score: 1
I stand corrected. Sun appears to have stealthed the change on this one. Good find. I had the generic download a long time ago. This is an update of some sort. Thanks for the pointer!
oh come on.... look at the links at least first...
on
Preview of Java 1.5
·
· Score: 1
Might just be me, but I don't see any prototype implementation on those links, except the generics prototype that has been available there for about 2-3 years since 1.3 came out. The other links only point to the JSR working group.
Another wonderful example of headline trolling. The generics implementation is very old news to the java developer community. It's just been under a lot of scrutiny before getting put into the language.
Just my thought, but I read it as the WebStart feature of auto-downloading and/or updating JRE/JDK versions to run various WebStart/JNLP enabled apps.
I don't think it's nearly as over-arching as MSFT's terms, and I expect if Sun was either more explicit or not in a country of lawsuits they would be able to make the disclaimer a bit less broad.
Heck. So could Microsoft if they didn't need to worry about getting sued over everything and anything.
Well when I unwrapped the tiBook I'm using, I was a bit to excited to look too closely at the license terms, but in general, you'd think that since Apache is included in OS X, Apple is a bit less paranoid, and wish to provide a tool, rather than a sale.
The article cites the workstation software. I'm assuming that then this applies only to the workstation version of XP? I ask because the quoted clause remarks
"...to use, access, display, or run other executable software residing on the Workstation..."
Use executable software residing on the Workstation? Does that bar the running of any server type or P2P type software that can respond to remote commands? A browser definitely "runs" the software that the webserver constitutes. Does it not?
So, no webservers or file sharing access from non-XP machines?
I've just written a quick letter to sales. I include it here to hopefully inspire a few more to respond to them in a civil and straight-forward manner in the hopes we can get them to reconsider:
Subject: bnetd.org, please reconsider
Dear Sirs,
I am a happy and proud owner of Warcraft II, Warcraft II Expansion, Diablo, Diablo II, Starcraft and Starcraft Brood Wars. I've enjoyed a great many hours playing your excellent games both stand alone and on Battle.net, and occasionally on bnetd when Battle.net was either having some splitting issues, was overloaded, or we were firewall imprisoned.
I am very disappointed in the legal bullying action that Blizzard has taken towards and open source reverse engineering project that in no way harms Blizzard's core properties or business. People using these systems don't see enough impressions on Battle.net to make a significant difference on ad revenue or impact, and in many cases would simply not be able to enjoy the multi-player aspect of the games without bnetd. This is akin to Blizzard attacking the Wine project that allows many of us to run a great set of games under Linux rather than having to use a less capable and less stable OS from Microsoft. Fortunately you also port to Macintosh, which I wish to thank you as well for a great Starcraft Carbon patch to make it OS X native. That's the best platform I've seen your game on yet.
I ask you to please rescind you legal action against the bnetd team, as they are only trying to help your business and make your games more accessible to a wider variety of players in a more diverse and distributed set of network scenarios.
I hope you will reconsider. If you continue the questionable enforcement of a bad law, I will be forced to act in accordance with my conscience and unhappily not purchase the Diablo II expansion, and further not purchase the Warcraft III game due to your company offering no substitutes to take the place of the products you have wrongly and unfairly taken action against. Products done by people on their own time without hope or expectation of compensation of any kind, but only in the interests of being able to play the games of yours that we have paid for.
sincerely, etcetc...[snip]
Feel free to use parts or all of the above in your communications if you think it will help.
SPARC dead? I'm not sure where you come across that idea. Having listened to a few talks down at JavaOne and chatted briefly with Marc Tremblay (head chip dude down there, father of MAJC and one designer of SPARC) they've already got design down on the next two levels of SPARC as the IV is experimental, and the V is the next production level as I understand it. MAJC seems to be the experimental platform they are using for smaller implementations and alternative ideas to be tried, based on some of Tremblay's theories.
I may be off base on some of the details, but Sun has a unified approach from top to bottom, from tools to silicon for the systems they plan to deliver. I doubt it will just throw in the towel. Ultimately, Sun ships iron, and they lead the market in their segment.
I don't see the basis for your assertion, and where you pulled 1B out of for cost I also don't know.
Alpha is AMD now, as that's where a good chunk of the people went. MIPS is still kicking, with the 14000 so far, but I won't speak to the future of that chip line. There's a lot of chip heads on this site with much better info than I on many of the lines.
Fair use is pretty slippery. And given a Google search, I did find a pretty good link here . wget may in fact be fair use or at least allowed if it is used only for your own purposes. IANAL as is obvious, and I do agree with your assesment of the ad blockers and Arriba in the previous form. I'm also very glad that the 9th circuit understands the value of Arriba in thumbnails.
Copyright I expect would be the actual statue that an act of plagiarism would be prosecuted under ultimately, although copyright has a wider purview of course.
I would have to say that the truth is between our intentionally polarized opinions. Law, especially copyright law, is most often designed to strike a balance. Like patent law, copyright law encouraged the publication of information but not putting that into the public domain, in the legal, source-code affected sense. I agree that a 75 year copyright can be viewed as excessive, but there is a concept of reward for labours in our market economies around the world.
As for _largeCorp, it is much harder to defend one's work in that case, but if you look at the case law, copyright law is much more defensible than patent law in many cases. You are allowed under fair use to cite portions of works and representations or summaries of works in such a way to extend or create new works as long as the new work is substantially original, or does not substantially consist of only one source. As for the "Dummies" chain, there is abuse of intent in statute, and that's really one of them. But as a reply to your post stated, that was trademark law, which is a very different beast.
But please remember that copyright is a balance, not weighted towards publication or towards the rights of the publisher, and only in doing so will many people undertake these efforts, so that they are rewarded. You can't take Stephen King's latest novel and publish it on the web for free due to copyright. He has control of that content. You can quote a few paragraphs and either revile his graphic horror or praise his literary excess and style. But you can't reproduce a substantial piece of his work without permission.
I am going to have to ask you to cut out telling me when I do that, as it's entirely possible that I'm going to inflict self-injury from laughing now. But thanks muchly.:-)
BlackStar
First people, get the facts straight and don't shoot from the hip from the badly "framed" byline. You may still link to a site from yours. That's not an issue. But you may not extract or appear to be the origin of information from that site by inline embedding or framing of subsections of that site.
Why is that bad? Why is that "against a free and open Internet"? That protects copyright. That's ALL. A photograph is copyright by the original author. So is a written work. So is source code. In fact, copyright and license is all that's stopping a popular enemy of many of the readers of this site from running off with a lot of source code and using it in proprietary products. This law protects the originators of work. It gives the author the ability to control and decide how that work will be used.
Anyone can still create excerpts of works for research, indexing and review purposes such as short links to stories, quotes of larger works, and now, thumbnails. This law extends the long-respected and venerated copyright law into the realm of digital images, and in what I personally feel is a responsible and very fair way.
For once, the law appears to be creating and extending a statute by case law in a fair way, in line with the intention of the original law, and it's getting slagged by some of the people it protects. How disappointing.
Try to weigh the rights of an author to own their labour vs. a free for all. This law protects and extends the right of each of us to create something, and either give it away, or sell it, or distribute it in some other novel way. Without that, anyone can take anything any of us does and use it in any way they wish, without our permission, and without compensation, and most importantly, without any concerns as to the intent for the use of the work originally.
Good gravy, I think you've caught me offguard offering a real, informed discussion on the topic! Many thanks for your attention.
Automatic deference, I admit, is a kneejerk from me to these individuals. When you're not an expert, you defer to experts, at least to start with.
Now granted, the SOAP server for argument's sake would *not* be directly in your internal network, but I expect likely in a "middle zone", not DMZ, but like a web server, a protected network with limited access to internal systems like J2EE and database servers. This doesn't really solve the problem though. All are going via port 80, and thus managing those services is less readily done via the firewall. Setting time zones of access, stateful inspection (if applicable) and some DoS defences (as I understand them, you're better to answer than I am, so treat these as questions worded as assumptions) become more difficult with one routed stream moving through the firewall. But that's really just cursory anyway, as the defence of a firewall is more high-level and perfunctory.
I totally agree that the problem comes when the IT department refuses to modify the firewall. That's why SOAP is being routed over the HTTP port by convention in the first place. That way they don't need to understand or worry about it, apparently. I expect we agree that this is the wrong way to approach the problem. The network engineers are part of the defence.
My large issue is that so many CGI scripts, which are really a precursor to web services, have been SO poorly written, especially with reference to security. Now you can write a web service in.NET with a few lines of code and a line identifying the method as a service. *poof*. You have a web service. And all the wonderful problems that go with trusting outside messages and directives. I personally think the concept is great, albeit not original (CORBA for one precursor), but that like so many things in network systems, it masks the vast majority of risks. SOAP is a prime example of a technology being viewed as always as a new, enabling technology, and not as a whole picture of a technology with inherent security concerns as well as business advantages.
And remember, the magnifying aspect of the automation of web services into the businesss processes make the security and reliability even *more* critical, as the amount of lost business and risk with errors is concurrently magnified.
I agree with Bruce and Adam's position not only by virtue of my respect for them, but also by my appreciation for the misapplication of so many technologies in the past by people not understanding the overall system. There will always be omissions and holes, but a balanced, rational approach is warranted with new connected technologies. SOAP has become "el buzzword supremo", and as such, the rampaging hordes of silver bullet hunters will be there, along with th e responsible adopters of the technology.
My hope is that people like Bruce, Adam, and by the sounds of it yourself would be able to present "the whole picture", by virtue of your understanding. It's not technical. It's psychological.
I'd enjoy taking this offline if you like, and if you don't mind, as I'd like to learn more about your views on this.
I agree in principle, but bundling services together is still a bad idea, and in fact Adam and Bruce state that rather clearly at the outset. The ability of the firewall to separate, manage and in some cases via stateful inspection assist in the security of each service separately is still a desirable methodology.
I really think you need to examine SOAP, especially as it relates to RPC. When you make a request to SOAP, it's an incoming request over HTTP. Coming from an outside party to your ticket selling system to reserve a flight. That's the whole idea of published web services.
You might with to browse the powerpoint from Microsoft itself detailing.NET and Web Services at this location and then try to get a grip on how it works before decrying "FUD!". If you think Adam and Bruce are offbase on security, you obviously have no concept of the capabilities, experience or dedication of either individual. As for myself, say what you want.:-)
MSFT could start by releasing all the crap they did with Kerberos and the 1 bit extension they put in to ensure incompatibility and create a semi-proprietary extension. Release that to the public with the code so that the experts can see if Kerberos was in any way broken or compromised by the MSFT implementation.
Doing that to the protocol was before Bill's memo, but it's indicative of at least a few people involved in security interoperability that really don't get it.
Removing that idiot extension to Kerberos that broke compatibility and modified without examination (at release -- it's been plenty examined now) is one thing they could start with. Release the modification, and the Kerberos networking code for MSFT OSes into the public security community. Interoperate and cooperate on the stuff that's really central in secure environments.
Or you could look at that act as proof that they want to own the security. Not necessarily create it.
There is a side thread in progress that touches on how SOAP is addressed in the article. I think SOAP deserves a lot more attention, especially as it affects MSFT, and the new.NET initiative.
SOAP is designed to use HTTP/HTTPS as the most common implementation of transport and protocol underneath. Schnier and Shostack touch on how poor a decision this is. I think this goes a lot further than many developers and companies are realizing.
You just removed your firewall.
The idea of SOAP is to allow IT services to be exposed as remotely addressable and usable procedures. Essentially with every web service or SOAP receiver, you have written a brand new server that parses XML protocol messages to decide on action. Thus every web service you create may have overrun, DoS and other exploits inherent in it, in your code, as you are executing paths based on a message from the outside. Just like a web server, ftp server or any other available server.
So now, everyone has to become better at security, to the point that the web services are safe. Ideally they should all run within a sandbox environment with restricted permissions, but considering SOAP authentication is based on HTTP authentication, the models may or may not match up properly.
Most importantly is that the SOAP specification team, including MSFT and the.NET portions pertaining to web services have basically increased the difficulty of every network administrator's job by stuffing all this over port 80.
Now if there is a vulnerability in a web service, the network admin has to take out port 80, probably taking down the web service, the web server, and who knows what else that's been tunnelled through there. They can't simply block a set port. UDDI could have advertised a port for the service as well, and stateful inspection could be implemented at some level on each service port to increase security and leverage off of the firewalls. Instead, a rat's nest of information is getting funnelled through http/https. The firewalls aren't designed for this, and the inspection task is only going to get more difficult as SOAP grows in popularity.
MSFT is always looking at first to market, and I can almost assure you that for that reason, SOAP was designed around port 80 and into the web server engines. I can also say with a fair bit of confidence that the first time MSFT gets beat to market due to a security review, that the security priority is going to get thrown right out the window of the executive windows at Microsoft if it causes the stock to slip.
That's somewhat incorrect. SOAP is illustrated as running over HTTP/HTTPS for the very reason that those protocols on default ports are already open. This was discussed in Microsoft's own announcement of the protocol. It had a pragmatic, if misguided purpose. Companies already had these ports open, and thus no additional work or effort would be required by the system administrators and network admins to enable the use of SOAP.
The idea is unfortunately short sighted, and will result in holes to be opened in what was previously a manageable service port. This was for expediency, not security. The SOAP spec team followed along as the adoption would be accelerated, but again, this was done without any real eye towards security.
I seriously hope MSFT takes these comments to heart and at least begins to adjust their practice and products to be more secure.
Then it evolves into netbeans, which has tabs to switch between modes (like debug, edit, gui layout etc.) where clicking the tab changes the family of windows in the workspace entirely.
Then you get modes which support free layouts of sorts.
It's an interesting concept. And obviously some alternatives to "whatever goes whereever" are slowly being challenged to help us get things done.
The actual article, especially the picture byline explains that due to the youthful nature of these stars, most of the fusion at the time is pure hydrogen, which gives off a very narrow, characteristic light from energy emmission. Only as a star gets older do other wavelengths begin to be emitted.
Redshift would alter the base frequency as well, but the article mentions that it's due to the age of the stars.
Slashdot Mirror
I went through the old 41cx, then a 48sx, and now a 49g. I actually like the 49g. It's much faster, can emulate the 48 key patterns, and with good ol' Kermit, I've had no trouble loading firmware and software (with a slight custom cable) from my iBook. It's got a whack o' RAM, and some decent dev capabilities of course, and a fair bit of in-memory libraries. Add to that the quite useful symbolic calculus that actually doesn't do a number of bizarre, useless Laplace transforms to get a solution, and it was a good upgrade. The ol' 48 got ripped off. I'm with you on the RPN though. Once you get used to it, it's faster than my old TI-66 with all those brackets.
You should not, as the poster pointed out, require a local phone service. Cell phones work quite well that way. The result was derived by knowing how the service is provisioned.
They also have a good overview of solar sailing on the project page here.
I stand corrected. Sun appears to have stealthed the change on this one. Good find. I had the generic download a long time ago. This is an update of some sort. Thanks for the pointer!
Another wonderful example of headline trolling. The generics implementation is very old news to the java developer community. It's just been under a lot of scrutiny before getting put into the language.
I don't think it's nearly as over-arching as MSFT's terms, and I expect if Sun was either more explicit or not in a country of lawsuits they would be able to make the disclaimer a bit less broad.
Heck. So could Microsoft if they didn't need to worry about getting sued over everything and anything.
Well when I unwrapped the tiBook I'm using, I was a bit to excited to look too closely at the license terms, but in general, you'd think that since Apache is included in OS X, Apple is a bit less paranoid, and wish to provide a tool, rather than a sale.
Use executable software residing on the Workstation? Does that bar the running of any server type or P2P type software that can respond to remote commands? A browser definitely "runs" the software that the webserver constitutes. Does it not?
So, no webservers or file sharing access from non-XP machines?
Feel free to use parts or all of the above in your communications if you think it will help.
Very true. I type corrected, and thanks for the clarification!
I may be off base on some of the details, but Sun has a unified approach from top to bottom, from tools to silicon for the systems they plan to deliver. I doubt it will just throw in the towel. Ultimately, Sun ships iron, and they lead the market in their segment.
I don't see the basis for your assertion, and where you pulled 1B out of for cost I also don't know.
Alpha is AMD now, as that's where a good chunk of the people went. MIPS is still kicking, with the 14000 so far, but I won't speak to the future of that chip line. There's a lot of chip heads on this site with much better info than I on many of the lines.
One decent, although dated summary is here
Please tell me there's more information you're basing this on than consumer workstation marketshare....
Wow. My first rating as a troll. Love to hear the justification on that. Apparently somebody with mod points didn't like my defense of copyright laws.
Copyright I expect would be the actual statue that an act of plagiarism would be prosecuted under ultimately, although copyright has a wider purview of course.
As for _largeCorp, it is much harder to defend one's work in that case, but if you look at the case law, copyright law is much more defensible than patent law in many cases. You are allowed under fair use to cite portions of works and representations or summaries of works in such a way to extend or create new works as long as the new work is substantially original, or does not substantially consist of only one source. As for the "Dummies" chain, there is abuse of intent in statute, and that's really one of them. But as a reply to your post stated, that was trademark law, which is a very different beast.
But please remember that copyright is a balance, not weighted towards publication or towards the rights of the publisher, and only in doing so will many people undertake these efforts, so that they are rewarded. You can't take Stephen King's latest novel and publish it on the web for free due to copyright. He has control of that content. You can quote a few paragraphs and either revile his graphic horror or praise his literary excess and style. But you can't reproduce a substantial piece of his work without permission.
I am going to have to ask you to cut out telling me when I do that, as it's entirely possible that I'm going to inflict self-injury from laughing now. But thanks muchly. :-)
BlackStar
Why is that bad? Why is that "against a free and open Internet"? That protects copyright. That's ALL. A photograph is copyright by the original author. So is a written work. So is source code. In fact, copyright and license is all that's stopping a popular enemy of many of the readers of this site from running off with a lot of source code and using it in proprietary products. This law protects the originators of work. It gives the author the ability to control and decide how that work will be used.
Anyone can still create excerpts of works for research, indexing and review purposes such as short links to stories, quotes of larger works, and now, thumbnails. This law extends the long-respected and venerated copyright law into the realm of digital images, and in what I personally feel is a responsible and very fair way.
For once, the law appears to be creating and extending a statute by case law in a fair way, in line with the intention of the original law, and it's getting slagged by some of the people it protects. How disappointing.
Try to weigh the rights of an author to own their labour vs. a free for all. This law protects and extends the right of each of us to create something, and either give it away, or sell it, or distribute it in some other novel way. Without that, anyone can take anything any of us does and use it in any way they wish, without our permission, and without compensation, and most importantly, without any concerns as to the intent for the use of the work originally.
Thus endeth the rant. Just think.
Automatic deference, I admit, is a kneejerk from me to these individuals. When you're not an expert, you defer to experts, at least to start with.
Now granted, the SOAP server for argument's sake would *not* be directly in your internal network, but I expect likely in a "middle zone", not DMZ, but like a web server, a protected network with limited access to internal systems like J2EE and database servers. This doesn't really solve the problem though. All are going via port 80, and thus managing those services is less readily done via the firewall. Setting time zones of access, stateful inspection (if applicable) and some DoS defences (as I understand them, you're better to answer than I am, so treat these as questions worded as assumptions) become more difficult with one routed stream moving through the firewall. But that's really just cursory anyway, as the defence of a firewall is more high-level and perfunctory.
I totally agree that the problem comes when the IT department refuses to modify the firewall. That's why SOAP is being routed over the HTTP port by convention in the first place. That way they don't need to understand or worry about it, apparently. I expect we agree that this is the wrong way to approach the problem. The network engineers are part of the defence.
My large issue is that so many CGI scripts, which are really a precursor to web services, have been SO poorly written, especially with reference to security. Now you can write a web service in .NET with a few lines of code and a line identifying the method as a service. *poof*. You have a web service. And all the wonderful problems that go with trusting outside messages and directives. I personally think the concept is great, albeit not original (CORBA for one precursor), but that like so many things in network systems, it masks the vast majority of risks. SOAP is a prime example of a technology being viewed as always as a new, enabling technology, and not as a whole picture of a technology with inherent security concerns as well as business advantages.
And remember, the magnifying aspect of the automation of web services into the businesss processes make the security and reliability even *more* critical, as the amount of lost business and risk with errors is concurrently magnified.
I agree with Bruce and Adam's position not only by virtue of my respect for them, but also by my appreciation for the misapplication of so many technologies in the past by people not understanding the overall system. There will always be omissions and holes, but a balanced, rational approach is warranted with new connected technologies. SOAP has become "el buzzword supremo", and as such, the rampaging hordes of silver bullet hunters will be there, along with th e responsible adopters of the technology.
My hope is that people like Bruce, Adam, and by the sounds of it yourself would be able to present "the whole picture", by virtue of your understanding. It's not technical. It's psychological.
I'd enjoy taking this offline if you like, and if you don't mind, as I'd like to learn more about your views on this.
I agree in principle, but bundling services together is still a bad idea, and in fact Adam and Bruce state that rather clearly at the outset. The ability of the firewall to separate, manage and in some cases via stateful inspection assist in the security of each service separately is still a desirable methodology.
You might with to browse the powerpoint from Microsoft itself detailing .NET and Web Services at this location and then try to get a grip on how it works before decrying "FUD!". If you think Adam and Bruce are offbase on security, you obviously have no concept of the capabilities, experience or dedication of either individual. As for myself, say what you want. :-)
Doing that to the protocol was before Bill's memo, but it's indicative of at least a few people involved in security interoperability that really don't get it.
Or you could look at that act as proof that they want to own the security. Not necessarily create it.
SOAP is designed to use HTTP/HTTPS as the most common implementation of transport and protocol underneath. Schnier and Shostack touch on how poor a decision this is. I think this goes a lot further than many developers and companies are realizing.
You just removed your firewall.
The idea of SOAP is to allow IT services to be exposed as remotely addressable and usable procedures. Essentially with every web service or SOAP receiver, you have written a brand new server that parses XML protocol messages to decide on action. Thus every web service you create may have overrun, DoS and other exploits inherent in it, in your code, as you are executing paths based on a message from the outside. Just like a web server, ftp server or any other available server.
So now, everyone has to become better at security, to the point that the web services are safe. Ideally they should all run within a sandbox environment with restricted permissions, but considering SOAP authentication is based on HTTP authentication, the models may or may not match up properly.
Most importantly is that the SOAP specification team, including MSFT and the .NET portions pertaining to web services have basically increased the difficulty of every network administrator's job by stuffing all this over port 80.
Now if there is a vulnerability in a web service, the network admin has to take out port 80, probably taking down the web service, the web server, and who knows what else that's been tunnelled through there. They can't simply block a set port. UDDI could have advertised a port for the service as well, and stateful inspection could be implemented at some level on each service port to increase security and leverage off of the firewalls. Instead, a rat's nest of information is getting funnelled through http/https. The firewalls aren't designed for this, and the inspection task is only going to get more difficult as SOAP grows in popularity.
MSFT is always looking at first to market, and I can almost assure you that for that reason, SOAP was designed around port 80 and into the web server engines. I can also say with a fair bit of confidence that the first time MSFT gets beat to market due to a security review, that the security priority is going to get thrown right out the window of the executive windows at Microsoft if it causes the stock to slip.
The idea is unfortunately short sighted, and will result in holes to be opened in what was previously a manageable service port. This was for expediency, not security. The SOAP spec team followed along as the adoption would be accelerated, but again, this was done without any real eye towards security.
I seriously hope MSFT takes these comments to heart and at least begins to adjust their practice and products to be more secure.
Then you get modes which support free layouts of sorts.
It's an interesting concept. And obviously some alternatives to "whatever goes whereever" are slowly being challenged to help us get things done.
Redshift would alter the base frequency as well, but the article mentions that it's due to the age of the stars.