You see, you assume you know the problem that FTP is solving, and you really don't. I have no intention of forcing people to send me an email asking for some data, nor do I intend on wasting my time sending them emails with all the data they want. You can come to my FTP site at any time, night or day, and get the data you want immediately, and you don't have to wait for me to see your email and have time to respond. Isn't that a Good Thing?
You can come to my website and get the same thing, and it is secured by TLS. The problem that FTP solves is better solved by other protocols. Even better, you can get nice, neat pages that organize the data in interesting ways, charts and graphs that support the data, and links to other websites that provide corroborating info. Heck, you might even be able to get a table that can sort itself when you click on the table columns....
You don' t know the problem being solved, so you don't get to define "better". No, turning on directory listings is a security hole, so the web server I run does not have that enabled.
WAT?
If showing the directory listing via HTTP is insecure, then it is just as insecure to show it over FTP. Given that you can turn on directory listings on a per-directory-subtree basis, that logic just doesn't hold up, barring some bizarre bug in which you can somehow get the option behavior of one directory to apply to another (which would be a *colossal* security bug, and the directory listing aspect would be the least of your worries at that point).
Turning off directory listings for security is roughly the computer security equivalent of painting over the name on your mailbox to keep people from breaking into your house....:-)
I've found no need to do that. I have no idea why you think this is relevant to a discussion about the use of FTP. I can't remember ever using FTP to install an OS.
That's because your user ID is about 40,000 too high to remember it.
In fact, I would say it is worse than a "blanket 'shut it off' protocol". It's more like a "kill it with fire" protocol at this point.
Well, you are free to have your own opinion, but making sound like it is a fact isn't convincing me. If you don't want to use it, that's fine. Denying that it has any use is simply arrogant.
And continuing to argue that it has some meaningful use when more modern solutions do the exact same job better is simply silly.
To be pedantic, FTPS is not really FTP. If you really want to support an FTPS-only solution, go for it, but since it isn't broadly supported, there's no reason to bother. And the unencrypted protocol is generally a bad idea by its very nature (authentication in the clear).
iPhones prove that cutting corners might not help with the cost anyway.
Jony Ive: iPhone corners are not cut. Rather, they are carefully extruded, given form and substance precisely, almost miraculously, ensuring that every iPhone's fit and finish is of the calibre that our users expect from Apple.
FTPS is to FTP what HTTPS is to HTTP, and mostly works the same.
FTPS is not nearly as broadly supported as FTP or HTTP, last I checked. In particular, unless things have changed in the last couple of years, Internet Explorer et al do not support FTPS, which makes the protocol basically DOA in a real-world environment.
You are technically correct that FTP has a resume command. Unfortunately, last I checked, Apple's URL handling infrastructure didn't support it, which AFAIK means neither does Safari. So basically, between that and the lack of FTPS in Internet Explorer, FTP is an absolute train wreck of half-supported functionality. By contrast, both TLS and download continuation work out-of-the-box with HTTP/HTTPS in all major browsers.
FTPS protects the command channel and your password using TLS, just as a webserver does.
Web servers also support digest authentication, which keeps the password secure against all but an exact replay of the request, even over unencrypted channels. AFAIK, there's nothing equivalent in FTP, unless you count Kerberos (shudder), which is even less broadly supported than FTPS.
While I agree any NAS maker provided FTP packages should include FTPS out of the box, I would also argue that requirement for a web server as well, requiring HTTPS out of the box.
Another big difference is that people naturally assume that anything you put on a web server can be seen by anybody. The password authentication inherent in FTP creates a false sense of security, which makes the non-TLS version even more problematic than it otherwise might be.
Yes, FTP is an old protocol. It is insecure. BUT, simple tools are often the correct tools. Do you have data you need to share with a lot of people? Anonymous FTP is a good way to do that.
No, it isn't. Anonymous FTP doesn't provide support for partial retransmission, which makes it an absolutely awful way to share data with a lot of people, unless the data is very small (in which case you should probably just paste it into an email).
It is far better to turn on directory listings in a web server and drop the files on a web server. You get the same overall behavior as FTP, but you gain the ability to pause downloads, the ability to secure those downloads if you want to (with TLS), the ability to have passwords that are not sent in the clear, etc.
FTP is not a blanket "shut it off" protocol.
It really is. There's nothing that can be done with FTP that can't be done better and, optionally, more securely with HTTP, other than maintain compatibility with some horrible legacy system that only supports FTP. So basically, if you still need to install twenty-year-old versions of Red Hat Linux, keep FTP around. Otherwise, it should die already.
In fact, I would say it is worse than a "blanket 'shut it off' protocol". It's more like a "kill it with fire" protocol at this point.
The fact that FTP is being used at all is a big red flag for me. Unless it's sitting inside a fully encrypted tunnel, an FTP password is so trivial to steal even if it isn't an obvious password. There may be a few cases where one has to use FTP, but where I have been forced to use it (old hardware), it's ringfenced like nuts, and I'm not going to have an FTP server open on the Internet, unless it's some sort of publicly available archive where I don't care who downloads off of it.
The fact that a NAS supports FTP at all is a *giant* red flag, and I'm not just talking about security. It should be somewhere between difficult and impossible to get an FTP server running on a NAS. A web server is superior in every way:
Web servers can be secured with TLS.
Web servers provide encrypted password transport even if the connection isn't encrypted (digest auth).
Web servers support continuing a download where you left off, rather than fetching the entire resource.
Other than for backwards compatibility with legacy systems that can only fetch data via FTP, there is absolutely no reason why anyone should set up an FTP server in this day and age, period. And this has been true for the better part of two decades. We're at the point where the vendors shouldn't even offer it as an option, and you should have to jailbreak the thing first. It should be hard enough that anyone attempting it will immediately recognize that he or she is doing something that he or she shouldn't be doing long before reaching the step where he or she turns on FTP — like three hours before.
PUBLIC IS PUBLIC. Where you go has *always* been public information, just the tracking has gotten more automatic.
From a legal perspective, that's not true. Article IV of the Constitution is considered to protect your right to travel freely, and you can't have a right to travel freely if you are being tracked, because there are places that would inherently be embarrassing if you were widely known to have traveled there.
The law has always recognized a difference between merely seeing that someone is in a place and tracking that person for a year to see where he or she goes. The latter, if surveillance is on an ongoing basis, is likely to cross the "reasonable" line and require a warrant (United States v. Jones). A license tracking system appears to be a prima facie attempt to sidestep that warrant requirement, and as such, is legally problematic.
Call me "not surprised" after passing umpteen machines in the security line with unprotected USB slots. One good boot and...
Next up: Girls Gone Wild, Airport Edition. See topless teens as only millimeter-wave scanners can see them. See gregarious grandmas with guns. And everything in between.
The only way to prevent people from seeing naked pictures of yourself is to never allow them to be taken in the first place. This includes the scanners at the airport.
Either way, there's little point in bothering to go after this guy. As soon as Apple starts having one of their Chinese manufacturing plants fab the boards, they'll make a few extras at the end of the run and ship them to whatever Chinese self-driving car wants to steal the IP. Besides, the value is in the software anyway, not the hardware. I can't imagine Apple having any interesting hardware IP in that space. Other than miniaturization of stuff like LIDAR, and maybe specialized DSP hardware for evaluating tensor models (in which all the interesting IP is chip design, not PCB design), most of the hardware tends to be off-the-shelf.
It is important to clarify that this applies only to pure business property. Blocking access to a drilling site might be acceptable morally, but blocking a public street never is, nor is blocking access to someone's home, apartment, dormitory, etc.
After a series of labor protests blocked access to a university campus near me, I and a few hundred other people made some fairly public comments asking why the police didn't arrest them for violation of CA vehicular code 21950(b). The four or five protests since then may have slowed traffic a bit, but they have not blocked it. When they blocked students' ability to get from their dorms to their places of employment, to get food off campus (and on-campus food was shut down for the protest), to get back to their dorms, etc., they crossed a major bright line.
As a rule, blocking vehicular traffic on a public road is illegal, subject to citation and, if necessary to prevent continued violation, arrest. You have a right to protest, but that right ends where the bumper of someone's car begins.
More to the point, as soon as your protest starts to negatively affect people who are not on the opposite side of the protest, it doesn't matter what your issue is or how important it might be. In the minds of those affected, you are in the wrong, which means you have lost the public's support, and your protest is effectively helping whatever you're protesting against.
Also, IMO, as a society, we protest entirely too often. At this point, it has almost completely lost its meaning. But that's another rant for another day.
I assure you there is NO WAY some magic iPhone cracker device (which remember still has to break through passcode security) is inexpensive enough there is going to be more than one per city, and probably only major cities at that. If there is a cop close at hand with one it would probably mean they had spent months gathering evidence on an extremely guilty person.
At $16k, they're barely half the cost of a police car. And I'd imagine they'll get cheaper in quantities.
So you have an hour to get the phone to the lab and have the warrant in hand before cracking it.
Nope. You have an hour for the cop to take the logger device out of his or her pocket, crack the phone, and extract the data into a storage device, under an "exigent circumstances" exception. In the best-case scenario, they then must obtain a warrant to extract the data from the storage device and rifle through it. Either way, you can safely assume that time-limited access means that warrant requirements will get weakened to accommodate that time limit. The only limit that won't inevitably lead to the rapid erosion of our fourth amendment rights is a zero-length limit.
It already exists. It's called "crack open the phone immediately". I'd be a lot more impressed with this technology if the user could configure the time all the way down to zero. There's no valid reason to allow new external devices to be probed while the phone is locked—not even one second after the phone is locked. The user can't do anything with those external devices without unlocking the device anyway.
This is, of course, as opposed to communicating with existing, known devices while the device is locked, which could be used by things like docks. Basically, it should stop probing for new devices immediately, and lock the port when the last device disappears, or immediately if there's nothing plugged into the port.
Of course the evolving government impositions are trending towards eventually mandating Zero emissions, which will essentially mean that all Combustion engines are going to be banned, and the most prone to failure equipment possible will be required to satisfy them: in other words, immature new technologies such as All-Electric or Alternative fuel.
You were mostly right up until that last part. Yes, eventually you will have to replace the battery pack, which most EV owners consider to be a consumable in much the same way that gasoline and fuel filters are consumables on ICE cars. Other than the battery, though, in principle, there's very little reason why an electric car should not basically run forever.
Whether you're talking about clogged carburetors, clogged injectors, worn piston rings, worn valve lifters, blown head gaskets, bent camshafts, leaking or bent valves, or any number of other interesting things that can go wrong mechanically with an ICE engine, there are simply a crazy number of parts that can wear out or fail, often catastrophically. With EVs, you have basically two or three bearings plus the rotor (which doesn't touch anything), and that's it other than a fixed gearbox, axles, differential, and wheels.
So EVs should be far more reliable over the long term than any ICE design can possibly be, because there are typically about two orders of magnitude fewer moving parts. Even if you took away all the emissions control systems in the ICE design (which usually do not cause the cars to fail, unless you consider failing a smog test to be "failing"), this would still be true.
Really everyone should be using width defined integer types at this point. If the switch from 32 bit to 64 bit computing didn't beat that through people's heads, I don't know what will.
No disagreement here. The point was that some languages enforce safety, and some gracefully let you shoot your own foot if you want to.
Java has some nice advantages in terms of not caring whether you're running on x86-64 or POWER10 or ARM.
Neither does C++.
The heck it doesn't. Ostensibly, if you somehow manage to write code that completely avoids C primitive types (numbers, for example) or are rigorous about always using fixed-size integer and floating point types, it is just a recompile, but it is a recompile, so:
Your build fleet has to build for multiple architectures.
Your test fleet has to run tests on multiple architectures.
This is a nonzero cost. And that's the best-case scenario.
The worst case scenario is one in which you get subtle truncation bugs that occur only on some of your machines and cause data corruption that goes undetected for six months, and in which, once you detect the corruption, you are contractually required to freeze your entire website in read-only mode for three weeks and hire a team of ten thousand temps to go through all of your database records manually, correlating six months' worth of logs with data from six-month-old backups to compute what the correct current values for those fields should be.
Reality is usually somewhere in-between the best-case and worst-case scenario.
It's funny that you expressed the opinion that people should not write fullstack purely in Javascript, but were OK with writing enterprise scale software in Java.
My objection is more to do with trying to do multiple disparate types of programming in the same language than with JS as a language or its performance. Performance-wise, compiled JS is pretty good these days.
It's funny that you expressed the opinion that people should not write fullstack purely in Javascript, but were OK with writing enterprise scale software in Java. Java is a decent language if you have more compute power than you really need, but not enough to run Python.
LOL. To some degree, yes. Like scripting languages, Java has some nice advantages in terms of not caring whether you're running on x86-64 or POWER10 or ARM. If you're deploying across a heterogeneous server fleet, this can be a significant advantage. That said, whether it outweighs the performance penalty is certainly debatable.
But the main reason for picking Java is that a lot of CS programs teach Java as their main programming language. This makes it somewhat easier to find large numbers of junior-grade programmers with CS degrees who know Java than Python.
The nice thing about making programming easy is that any idiot can write software.
The bad thing about making programming easy is that any idiot can write software.
A good craftsperson does not blame the tools — not because you could hand that person terrible tools and get the same results as with great tools, but rather because the person would know what various tools do well, and would find ways to work within their limitations to create something good.
The same is true for programming languages. Different languages are good at different things. I'd rather smash my head repeatedly with a ball-peen hammer than deal with giant steaming piles of templates, but stick embedded C++ in the kernel without all that STL baggage or exception handling or multiple inheritance or RTTI or any of the other junk that makes the C++ runtime so bloated, and you end up with a halfway decent language for writing device driver stacks.
Need to use piles of regular expressions for some reason? Perl.
Need a lightweight template-based web backend language for a small-ish website? PHP.
Need a language for writing client code? Objective-C.
Need a language for writing enterprise-scale server code? Java.
Need a language for full-stack development by a single development team? Javascript, but don't do that. Really. Don't do that.
Slashdot Mirror
You can come to my website and get the same thing, and it is secured by TLS. The problem that FTP solves is better solved by other protocols. Even better, you can get nice, neat pages that organize the data in interesting ways, charts and graphs that support the data, and links to other websites that provide corroborating info. Heck, you might even be able to get a table that can sort itself when you click on the table columns....
WAT?
If showing the directory listing via HTTP is insecure, then it is just as insecure to show it over FTP. Given that you can turn on directory listings on a per-directory-subtree basis, that logic just doesn't hold up, barring some bizarre bug in which you can somehow get the option behavior of one directory to apply to another (which would be a *colossal* security bug, and the directory listing aspect would be the least of your worries at that point).
Turning off directory listings for security is roughly the computer security equivalent of painting over the name on your mailbox to keep people from breaking into your house.... :-)
That's because your user ID is about 40,000 too high to remember it.
And continuing to argue that it has some meaningful use when more modern solutions do the exact same job better is simply silly.
To be pedantic, FTPS is not really FTP. If you really want to support an FTPS-only solution, go for it, but since it isn't broadly supported, there's no reason to bother. And the unencrypted protocol is generally a bad idea by its very nature (authentication in the clear).
Apple AND Microsoft, in different ways. This is a strong hint that the industry as a whole abandoned the protocol a long time ago.
Jony Ive: iPhone corners are not cut. Rather, they are carefully extruded, given form and substance precisely, almost miraculously, ensuring that every iPhone's fit and finish is of the calibre that our users expect from Apple.
FTPS is not nearly as broadly supported as FTP or HTTP, last I checked. In particular, unless things have changed in the last couple of years, Internet Explorer et al do not support FTPS, which makes the protocol basically DOA in a real-world environment.
You are technically correct that FTP has a resume command. Unfortunately, last I checked, Apple's URL handling infrastructure didn't support it, which AFAIK means neither does Safari. So basically, between that and the lack of FTPS in Internet Explorer, FTP is an absolute train wreck of half-supported functionality. By contrast, both TLS and download continuation work out-of-the-box with HTTP/HTTPS in all major browsers.
Web servers also support digest authentication, which keeps the password secure against all but an exact replay of the request, even over unencrypted channels. AFAIK, there's nothing equivalent in FTP, unless you count Kerberos (shudder), which is even less broadly supported than FTPS.
Another big difference is that people naturally assume that anything you put on a web server can be seen by anybody. The password authentication inherent in FTP creates a false sense of security, which makes the non-TLS version even more problematic than it otherwise might be.
No, it isn't. Anonymous FTP doesn't provide support for partial retransmission, which makes it an absolutely awful way to share data with a lot of people, unless the data is very small (in which case you should probably just paste it into an email).
It is far better to turn on directory listings in a web server and drop the files on a web server. You get the same overall behavior as FTP, but you gain the ability to pause downloads, the ability to secure those downloads if you want to (with TLS), the ability to have passwords that are not sent in the clear, etc.
It really is. There's nothing that can be done with FTP that can't be done better and, optionally, more securely with HTTP, other than maintain compatibility with some horrible legacy system that only supports FTP. So basically, if you still need to install twenty-year-old versions of Red Hat Linux, keep FTP around. Otherwise, it should die already.
In fact, I would say it is worse than a "blanket 'shut it off' protocol". It's more like a "kill it with fire" protocol at this point.
The fact that a NAS supports FTP at all is a *giant* red flag, and I'm not just talking about security. It should be somewhere between difficult and impossible to get an FTP server running on a NAS. A web server is superior in every way:
Other than for backwards compatibility with legacy systems that can only fetch data via FTP, there is absolutely no reason why anyone should set up an FTP server in this day and age, period. And this has been true for the better part of two decades. We're at the point where the vendors shouldn't even offer it as an option, and you should have to jailbreak the thing first. It should be hard enough that anyone attempting it will immediately recognize that he or she is doing something that he or she shouldn't be doing long before reaching the step where he or she turns on FTP — like three hours before.
No, no, it's Skil. He's complaining that the immigrant workers leach off the saws and drills of local landowners instead of bringing their own.
From a legal perspective, that's not true. Article IV of the Constitution is considered to protect your right to travel freely, and you can't have a right to travel freely if you are being tracked, because there are places that would inherently be embarrassing if you were widely known to have traveled there.
The law has always recognized a difference between merely seeing that someone is in a place and tracking that person for a year to see where he or she goes. The latter, if surveillance is on an ongoing basis, is likely to cross the "reasonable" line and require a warrant (United States v. Jones). A license tracking system appears to be a prima facie attempt to sidestep that warrant requirement, and as such, is legally problematic.
Next up: Girls Gone Wild, Airport Edition. See topless teens as only millimeter-wave scanners can see them. See gregarious grandmas with guns. And everything in between.
The only way to prevent people from seeing naked pictures of yourself is to never allow them to be taken in the first place. This includes the scanners at the airport.
Either way, there's little point in bothering to go after this guy. As soon as Apple starts having one of their Chinese manufacturing plants fab the boards, they'll make a few extras at the end of the run and ship them to whatever Chinese self-driving car wants to steal the IP. Besides, the value is in the software anyway, not the hardware. I can't imagine Apple having any interesting hardware IP in that space. Other than miniaturization of stuff like LIDAR, and maybe specialized DSP hardware for evaluating tensor models (in which all the interesting IP is chip design, not PCB design), most of the hardware tends to be off-the-shelf.
On the contrary. If most users are using something that limits the time window, it will be "necessary" to have more of these.
Unfortunately, most of them don't vote.
It is important to clarify that this applies only to pure business property. Blocking access to a drilling site might be acceptable morally, but blocking a public street never is, nor is blocking access to someone's home, apartment, dormitory, etc.
After a series of labor protests blocked access to a university campus near me, I and a few hundred other people made some fairly public comments asking why the police didn't arrest them for violation of CA vehicular code 21950(b). The four or five protests since then may have slowed traffic a bit, but they have not blocked it. When they blocked students' ability to get from their dorms to their places of employment, to get food off campus (and on-campus food was shut down for the protest), to get back to their dorms, etc., they crossed a major bright line.
As a rule, blocking vehicular traffic on a public road is illegal, subject to citation and, if necessary to prevent continued violation, arrest. You have a right to protest, but that right ends where the bumper of someone's car begins.
More to the point, as soon as your protest starts to negatively affect people who are not on the opposite side of the protest, it doesn't matter what your issue is or how important it might be. In the minds of those affected, you are in the wrong, which means you have lost the public's support, and your protest is effectively helping whatever you're protesting against.
Also, IMO, as a society, we protest entirely too often. At this point, it has almost completely lost its meaning. But that's another rant for another day.
At $16k, they're barely half the cost of a police car. And I'd imagine they'll get cheaper in quantities.
Nope. You have an hour for the cop to take the logger device out of his or her pocket, crack the phone, and extract the data into a storage device, under an "exigent circumstances" exception. In the best-case scenario, they then must obtain a warrant to extract the data from the storage device and rifle through it. Either way, you can safely assume that time-limited access means that warrant requirements will get weakened to accommodate that time limit. The only limit that won't inevitably lead to the rapid erosion of our fourth amendment rights is a zero-length limit.
It already exists. It's called "crack open the phone immediately". I'd be a lot more impressed with this technology if the user could configure the time all the way down to zero. There's no valid reason to allow new external devices to be probed while the phone is locked—not even one second after the phone is locked. The user can't do anything with those external devices without unlocking the device anyway.
This is, of course, as opposed to communicating with existing, known devices while the device is locked, which could be used by things like docks. Basically, it should stop probing for new devices immediately, and lock the port when the last device disappears, or immediately if there's nothing plugged into the port.
You were mostly right up until that last part. Yes, eventually you will have to replace the battery pack, which most EV owners consider to be a consumable in much the same way that gasoline and fuel filters are consumables on ICE cars. Other than the battery, though, in principle, there's very little reason why an electric car should not basically run forever.
Whether you're talking about clogged carburetors, clogged injectors, worn piston rings, worn valve lifters, blown head gaskets, bent camshafts, leaking or bent valves, or any number of other interesting things that can go wrong mechanically with an ICE engine, there are simply a crazy number of parts that can wear out or fail, often catastrophically. With EVs, you have basically two or three bearings plus the rotor (which doesn't touch anything), and that's it other than a fixed gearbox, axles, differential, and wheels.
So EVs should be far more reliable over the long term than any ICE design can possibly be, because there are typically about two orders of magnitude fewer moving parts. Even if you took away all the emissions control systems in the ICE design (which usually do not cause the cars to fail, unless you consider failing a smog test to be "failing"), this would still be true.
No disagreement here. The point was that some languages enforce safety, and some gracefully let you shoot your own foot if you want to.
There are two hard problems in computer science: naming things, cache invalidation, and off-by-one (decade) errors.
I felt sure I was about to see a Lethal Weapon clip.
Java has some nice advantages in terms of not caring whether you're running on x86-64 or POWER10 or ARM.
Neither does C++.
The heck it doesn't. Ostensibly, if you somehow manage to write code that completely avoids C primitive types (numbers, for example) or are rigorous about always using fixed-size integer and floating point types, it is just a recompile, but it is a recompile, so:
This is a nonzero cost. And that's the best-case scenario.
The worst case scenario is one in which you get subtle truncation bugs that occur only on some of your machines and cause data corruption that goes undetected for six months, and in which, once you detect the corruption, you are contractually required to freeze your entire website in read-only mode for three weeks and hire a team of ten thousand temps to go through all of your database records manually, correlating six months' worth of logs with data from six-month-old backups to compute what the correct current values for those fields should be.
Reality is usually somewhere in-between the best-case and worst-case scenario.
My objection is more to do with trying to do multiple disparate types of programming in the same language than with JS as a language or its performance. Performance-wise, compiled JS is pretty good these days.
LOL. To some degree, yes. Like scripting languages, Java has some nice advantages in terms of not caring whether you're running on x86-64 or POWER10 or ARM. If you're deploying across a heterogeneous server fleet, this can be a significant advantage. That said, whether it outweighs the performance penalty is certainly debatable.
But the main reason for picking Java is that a lot of CS programs teach Java as their main programming language. This makes it somewhat easier to find large numbers of junior-grade programmers with CS degrees who know Java than Python.
Yeah, as I always have said:
A good craftsperson does not blame the tools — not because you could hand that person terrible tools and get the same results as with great tools, but rather because the person would know what various tools do well, and would find ways to work within their limitations to create something good.
The same is true for programming languages. Different languages are good at different things. I'd rather smash my head repeatedly with a ball-peen hammer than deal with giant steaming piles of templates, but stick embedded C++ in the kernel without all that STL baggage or exception handling or multiple inheritance or RTTI or any of the other junk that makes the C++ runtime so bloated, and you end up with a halfway decent language for writing device driver stacks.
Need to use piles of regular expressions for some reason? Perl.
Need a lightweight template-based web backend language for a small-ish website? PHP.
Need a language for writing client code? Objective-C.
Need a language for writing enterprise-scale server code? Java.
Need a language for full-stack development by a single development team? Javascript, but don't do that. Really. Don't do that.
And so on.
... when your network infrastructure was certified secure by the Fonz.
Aaaaaaaaaaaaaaaaaaaay.