Supply Chain Management. Dell's profitability over other manufacturers comes largely from their ability to negotiate large-scale, very specific deals for parts arrival. They don't have shelves full of ten thousand hard drives waiting for orders to come in, but rather have tightly integrated systems with HD manufacturers so that they can have just the number they need to fill the day's orders arrive the next day for assembly* (actually, I think it's more based around EXACT, to-the-minute shipment arrival times for a standard quantity, but the idea of high-precision inventory management remains the same). Same with processors, motherboards, cases, displays, and everything else they sell. In other words, Dell's success is due to their lack of warehouses of spare parts - and that entire system is built on predictability.
So to answer your question: when some guy wants to order a spare part for his machine - even some ten-cent part being sold for $150, the lack of data about what machine it's for can very easily cause far more than the "lost" $149.90 in damages to that predictability. The extra minute it may take for their next shipment of drive trays to come in because someone had to order a spare could easily cost them tens of thousands of dollars of lost productivity on their assembly lines.
*Give or take, but that's the goal of the system. Obviously having that level of precision is pretty much a logistical impossibility, but Dell (last I looked into it, at least) is probably second only to Wal-Mart in their inventory management. Yes, Wal-Mart. How many other companies in the world have the data to know to stock up on strawberry pop-tarts in the couple of days before an impending hurricane?
Most anyone can grow food, the past couple of weeks I've been working on my garden, most people can not write their own programs though.
Nonsense. Anyone is capable of writing their own software, just as anyone is capable of keeping and maintaining their own garden. Both have some barriers to entry, but by far the biggest are time commitments and interest. My mother has zero interest in programming her own apps, just as I have zero interest in growing my own food. If she had any interest in programming she could learn how to write code, and if I had any interest in gardening I could go out and buy a shovel and some seeds. She would probably write very poor code at first, and I would probably keep a terrible garden; both of us could improve with time.
Well, let's assume that someone rips tracks from some CD at 256k MP3 and puts them in a torrent for all to download. Let's assume that I've purchased that same CD and ripped a copy to my machine using the same encoder and settings. Shouldn't both the pirated and my own legal copy be identical? You're taking two identical files, running them both through the same algorithm (despite being an algorithm that results in lossy compression) and getting an output. How would they then be able to show that the file was pirated?
I haven't tested this, but if f(x) = y isn't always true, then I'd assume something went wrong (unless of course f(x) is designed to give random outputs, which I'd think isn't the case for audio compression algorithms).
Foo\$n would print $n in the Foo namespace. I think. Strictly speaking, you should wrap it in curly braces if you're using anything other than a "non-complex" (for lack of a better term) variable, including array contents and object members.
If variable $Foo was a string that contained the name of some namespace ("bar", for example), then if it wasn't in a quoted string context it would look for constant bar\n, but constants aren't echoed when quoted.
That said, I still think the original choice of:: instead of \ as a namespace separator made a lot more sense. I looked at the discussion and the switch did make a hint of sense, but a forward slash (or ANYTHING that wasn't the escape character) would have been a much better choice. Maybe ~? I don't think that's used anywhere else.
Look into ini_set(). There are a couple odd things you can't override through that, but 95% of the standard configuration can be changed that way. The only thing that doesn't that immediately comes to mind is one of the magic_quotes settings, presumably because the superglobals have already been established by the time you've hit the override function - and magic quotes is finally going away in php6 so that'll be a non-issue moving forward.
Well, I once had to use PHP to re-import a MSSQL DB that was something like 25GB because no SQL machine was able to import even one of the 133 (?) files that made up the DB contents. Had to leave it running for something like 17 hours, but I think it ended up getting the job done well enough for what needed to be done.
But yeah, I tend to avoid dealing with any large files in PHP whenever possible.
It won't happen to the base functions simply for backwards-compatibility, but given that namespace support is being added into PHP6 (I think it's also in 5.3; I have 5.2.6 on my machine so I don't know for sure) they could re-map all of those old functions in the global namespace into new logically-named and consistent functions. Array and string manipulation functions come to mind as the worst offenders, but there's plenty of other bad stuff as well. I think a lot of it would do well to be remade into built-in classes given that PHP5 has pretty solid OO support already (at least compared to 4). Nothing stopping anyone from doing that on their own right now; it just seems like a lot of unnecessary work when it would fit well in SPL.
Not to defend Apple for this policy, but there's a pretty clear distinction between "any random page on the internet" and "content obtained through the Apple-sanctioned App Store".
If you don't have a text messaging plan, that'll cost you about $25 to get a party of that size, assuming 100% turnout. And it's still quite a bit more work selecting 100+ people to send a text to (unless your phone has a "text my entire phonebook" button, which is a disaster waiting to happen) than sending out a tweet and having people show up.
Nobody at Apple is stupid enough to buy an SMS service.
Actually, when you phrase it like that, it really makes perfect sense. As a micro-messaging service, it wouldn't make much sense as an Apple property. As something to replace SMS, I would actually see it being a very valuable addition to their lineup as an iPhone customer (provided it stays as open as it is now). Apple has already been able to bully AT&T into giving up MUCH more than anyone would have thought possible simply by being so damn successful over the last few years, it's actually not out of the question that they'd want to push that further.
Of note: I won't pay any extra for SMS messages on my iPhone. The concept of paying $0.25 for 160B of data which is built into the cellular service overhead and costs them absolutely nothing to maintain is absurd. $5/mo for unlimited texting is only slightly less insane. I get 200 texts built into my normal plan (first-gen iPhone) which is fine for what I do. However, it would be a fantastic value-add to get around that entirely by, in effect, replacing the SMS app on the phone with a Twitter client of sorts (at least for direct messages) - even if only to spite AT&T. I already use DMs in favor of SMS for my friends that have a twitter account (most of them) simply because it doesn't count towards my text message limit.
There is, of course, no shortage of Twitter apps on the iPhone (nor most smartforms I think; standard phones can still do it over sms) so it's not much of an issue except for the lack of "push" functionality. I don't know how that will be handled in the 3.0 SDK but I doubt it'll be as seamless as SMS and phone calls are since there's the intermediate server that everything funnels through.
If they could pull off something where they go behind the carriers' backs to make it a free, open protocol to contact cellular phones, it would be awesome. Doesn't matter whether it's Twitter or not, but it's already got a large userbase and is well-suited to the application. The only reason that Twitter is even relevant to the picture is that it seems like the only way to, in effect, make SMS free* - as it should be.
*Maybe a buck a month for unlimited. The current situation where bandwidth to the ISS is cheaper goes well beyond ridiculous. I don't think you could use an entire megabyte of bandwidth a month over SMS.
During the time of the YouTube acquisition, it was often discussed that they might have done it in order to set precedents for copyright laws and other distribution-related stuff (net neutrality, etc.) since Google has better lawyers than YouTube could have hoped to afford at the time. Theory being that if Youtube was sued, they wouldn't have the funding to fight unfair charges and a precedent would be set against them and other providers of free content; whereas with Google backing them they'd have the funding and/or legal team to win and have it go in their favor. It sucks that our court system favors who has the better lawyers and not what's actually in the law books, but that's life.
Skype, on the other hand, was just a stupid choice by eBay. But you can't expect much different from a company that's founded around the very concept of bad buying decisions.
Chances are that if a student is bright enough to reverse-engineer their network protocols in order to cheat, s/he should be passing anyways. Doubly so if the password is "pencil" and we soon find ourselves on the brink of WWIII.
But in all seriousness, their client-server auth protocols are such a long-tail problem compared to people alt-tabbing over to Wikipedia that it's pretty much irrelevant. Less so for interacting with the admin interface, but they're probably using something a bit more transactional than a giant blob of XML, and I'd like to think that teachers would notice if someone goes from failing to straight-A student overnight.
Don't get me wrong... I just finished a massive rant about the importance of security elsewhere. But it's not like there's money or bombs on the other side of the connection, just test grades.
Well, about half of the discussions that I had during my middle and high school career regarding careers involved discussing how crappy teachers' pay is - not a terribly inviting way to get new people into the field. However, a teachers pay structure that's more of a meritocracy rather than looking for a cell on a table of years of service and level of education (this was how it was done at my HS; I don't know about anywhere else) would certainly give an incentive to be a better teacher - outside of the fundamental flaw of a meritocracy in that it brings out the worst in people as they try to cheat the system. Not really an easy problem to solve, but it's not insurmountable. If nothing else, I still see it as overall being more productive than systems structured around equality and political correctness - all teachers are NOT equally skilled, and should not be compensated as such.
The cause of the issue doesn't stop it from being a perfectly valid issue. Obviously it means we need to go about addressing said issue in a different way, but it doesn't invalidate an observation.
There are of course exceptions to any generalization, but stereotypes and generalizations exist BECAUSE the observed trait is accurate sufficiently often. When you're dealing with statistical sample sizes measured in millions or tens of millions, you can draw some pretty accurate results.
Yes, correlation is not causation, but that's completely irrelevant to the discussion. If you're drawing conclusions from the results of the ENTIRE standardized testing results from one year and notice that (all other things being equal) one race scores consistently higher than another, it's perfectly valid to use those results in a discussion however unfair those results seem.
That's not Facebook's fault. They offer you the controls to lock down your profile as much or as little as you want. Half of my Facebook friends I've never met and we're only playing a couple of games together online; they go in my "games" friend list on FB and have access to precisely none of my personal information. What information I've made public was done so intentionally, mostly to try and get a little extra Google juice.
You can flag just about any content on Facebook as inappropriate -especially photos and videos. Presumably only flagged content is reviewed at all. They are dealing with billions of photos after all.
Actually, last I checked, Qik is only available on jailbroken phones, and they're... I wouldn't say mainstream but large enough to at least make it noteworthy. In their case it's because they had to hack some sort of crude video functionality into the built-in camera which you can't do through Apple's APIs rather than censorship.
They have complete control of the App Store. There's absolutely nothing stopping them from forcing developers to rate their apps for intended audience, much like the TV ratings (Y, Y7, 14, MA, with the D,S,L,V flags) or video games. It allows them to still disallow outright porn while flagging potentially-offensive software appropriately.
Because some nitwit will come by with an infected thumb drive which will grab files and post them to some server the next time it's on an internet-enabled machine.
Microsoft put itself in that situation. Safari and Firefox (and I'd assume Opera, I honestly don't know a damn thing about it) render to the same standards, plus support some sort of conditional stuff for upcoming standards (see: -moz-border-radius; -webkit-border-radius. Also note that they have slightly different syntaxes right now since the standard isn't finalized). As time moves forward they've come to also follow additional, newer standards, but that doesn't present an issue for backwards compatibility.
IE6 and IE7 both fail to render according to standards correctly, as we all well know. That means that on the corporate side, if you have apps that have been designed around this lack of standards-adherence, your stuff may well break in a future version as the browser suddenly follows the standards that it once ignored. Thankfully IE8 includes its fallback "compatibility" mode which will render standards-compliant sites according to standards*, and will use fallback modes for sites that don't adhere to the standards. This does a fantastic job eliminating that "will my app break if I make this upgrade?" concern, which is the primary reason that would stop corporate upgrades.
As far as home users that haven't upgraded yet - it's relatively safe to assume that most of these users never upgrade anything (despite many being security patches, etc) due to indifference, rather than avoidance. I'd bet a very large portion of home IE6 installs are on XP SP2 or earlier, with a number of unpatched security vulnerabilities. They probably disabled auto updates because they were annoyed by the dialog boxes and have been unknowingly sending out zombified spam for years.
*In my testing, this has always been the case, except for a select few newer CSS properties. As all of these add a little polish to the page but don't in any way affect layout (text-shadow, -X-box-shadow, -X-border-radius, @font-face, etc), this is fully a non-issue. Javascript libraries completely eliminate cross-browser scripting issues (through their own hacks as-needed, I expect), so it's not even on my radar as a concern.
What sort of SSB apps even exist for Windows? I'm aware of Fluid.app on OS X, but that uses the default system rendering engine, which is whatever version of Safari you have installed (well, technically the version of Webkit that your install of Safari uses, which might as well be the same thing). AFAIK, doing the same thing on Windows would be based off the currently installed version of IE; I'd assume that packaging IE6 in a Windows SSB would violate some sort of redistribution clause in the EULA. You'd be ok with Webkit or Gecko as both are open-source, but if your site ran properly in either of those rendering engines then you wouldn't have this problem in the first place.
Slashdot Mirror
Supply Chain Management. Dell's profitability over other manufacturers comes largely from their ability to negotiate large-scale, very specific deals for parts arrival. They don't have shelves full of ten thousand hard drives waiting for orders to come in, but rather have tightly integrated systems with HD manufacturers so that they can have just the number they need to fill the day's orders arrive the next day for assembly* (actually, I think it's more based around
EXACT, to-the-minute shipment arrival times for a standard quantity, but the idea of high-precision inventory management remains the same). Same with processors, motherboards, cases, displays, and everything else they sell. In other words, Dell's success is due to their lack of warehouses of spare parts - and that entire system is built on predictability.
So to answer your question: when some guy wants to order a spare part for his machine - even some ten-cent part being sold for $150, the lack of data about what machine it's for can very easily cause far more than the "lost" $149.90 in damages to that predictability. The extra minute it may take for their next shipment of drive trays to come in because someone had to order a spare could easily cost them tens of thousands of dollars of lost productivity on their assembly lines.
*Give or take, but that's the goal of the system. Obviously having that level of precision is pretty much a logistical impossibility, but Dell (last I looked into it, at least) is probably second only to Wal-Mart in their inventory management. Yes, Wal-Mart. How many other companies in the world have the data to know to stock up on strawberry pop-tarts in the couple of days before an impending hurricane?
Most anyone can grow food, the past couple of weeks I've been working on my garden, most people can not write their own programs though.
Nonsense. Anyone is capable of writing their own software, just as anyone is capable of keeping and maintaining their own garden. Both have some barriers to entry, but by far the biggest are time commitments and interest. My mother has zero interest in programming her own apps, just as I have zero interest in growing my own food. If she had any interest in programming she could learn how to write code, and if I had any interest in gardening I could go out and buy a shovel and some seeds. She would probably write very poor code at first, and I would probably keep a terrible garden; both of us could improve with time.
Well, let's assume that someone rips tracks from some CD at 256k MP3 and puts them in a torrent for all to download. Let's assume that I've purchased that same CD and ripped a copy to my machine using the same encoder and settings. Shouldn't both the pirated and my own legal copy be identical? You're taking two identical files, running them both through the same algorithm (despite being an algorithm that results in lossy compression) and getting an output. How would they then be able to show that the file was pirated?
I haven't tested this, but if f(x) = y isn't always true, then I'd assume something went wrong (unless of course f(x) is designed to give random outputs, which I'd think isn't the case for audio compression algorithms).
It'll print $Foo followed by a newline.
Foo\$n would print $n in the Foo namespace. I think. Strictly speaking, you should wrap it in curly braces if you're using anything other than a "non-complex" (for lack of a better term) variable, including array contents and object members.
If variable $Foo was a string that contained the name of some namespace ("bar", for example), then if it wasn't in a quoted string context it would look for constant bar\n, but constants aren't echoed when quoted.
That said, I still think the original choice of :: instead of \ as a namespace separator made a lot more sense. I looked at the discussion and the switch did make a hint of sense, but a forward slash (or ANYTHING that wasn't the escape character) would have been a much better choice. Maybe ~? I don't think that's used anywhere else.
Look into ini_set(). There are a couple odd things you can't override through that, but 95% of the standard configuration can be changed that way. The only thing that doesn't that immediately comes to mind is one of the magic_quotes settings, presumably because the superglobals have already been established by the time you've hit the override function - and magic quotes is finally going away in php6 so that'll be a non-issue moving forward.
Well, I once had to use PHP to re-import a MSSQL DB that was something like 25GB because no SQL machine was able to import even one of the 133 (?) files that made up the DB contents. Had to leave it running for something like 17 hours, but I think it ended up getting the job done well enough for what needed to be done.
But yeah, I tend to avoid dealing with any large files in PHP whenever possible.
It won't happen to the base functions simply for backwards-compatibility, but given that namespace support is being added into PHP6 (I think it's also in 5.3; I have 5.2.6 on my machine so I don't know for sure) they could re-map all of those old functions in the global namespace into new logically-named and consistent functions. Array and string manipulation functions come to mind as the worst offenders, but there's plenty of other bad stuff as well. I think a lot of it would do well to be remade into built-in classes given that PHP5 has pretty solid OO support already (at least compared to 4). Nothing stopping anyone from doing that on their own right now; it just seems like a lot of unnecessary work when it would fit well in SPL.
Not to defend Apple for this policy, but there's a pretty clear distinction between "any random page on the internet" and "content obtained through the Apple-sanctioned App Store".
If you don't have a text messaging plan, that'll cost you about $25 to get a party of that size, assuming 100% turnout. And it's still quite a bit more work selecting 100+ people to send a text to (unless your phone has a "text my entire phonebook" button, which is a disaster waiting to happen) than sending out a tweet and having people show up.
Nobody at Apple is stupid enough to buy an SMS service.
Actually, when you phrase it like that, it really makes perfect sense. As a micro-messaging service, it wouldn't make much sense as an Apple property. As something to replace SMS, I would actually see it being a very valuable addition to their lineup as an iPhone customer (provided it stays as open as it is now). Apple has already been able to bully AT&T into giving up MUCH more than anyone would have thought possible simply by being so damn successful over the last few years, it's actually not out of the question that they'd want to push that further.
Of note: I won't pay any extra for SMS messages on my iPhone. The concept of paying $0.25 for 160B of data which is built into the cellular service overhead and costs them absolutely nothing to maintain is absurd. $5/mo for unlimited texting is only slightly less insane. I get 200 texts built into my normal plan (first-gen iPhone) which is fine for what I do. However, it would be a fantastic value-add to get around that entirely by, in effect, replacing the SMS app on the phone with a Twitter client of sorts (at least for direct messages) - even if only to spite AT&T. I already use DMs in favor of SMS for my friends that have a twitter account (most of them) simply because it doesn't count towards my text message limit.
There is, of course, no shortage of Twitter apps on the iPhone (nor most smartforms I think; standard phones can still do it over sms) so it's not much of an issue except for the lack of "push" functionality. I don't know how that will be handled in the 3.0 SDK but I doubt it'll be as seamless as SMS and phone calls are since there's the intermediate server that everything funnels through.
If they could pull off something where they go behind the carriers' backs to make it a free, open protocol to contact cellular phones, it would be awesome. Doesn't matter whether it's Twitter or not, but it's already got a large userbase and is well-suited to the application. The only reason that Twitter is even relevant to the picture is that it seems like the only way to, in effect, make SMS free* - as it should be.
*Maybe a buck a month for unlimited. The current situation where bandwidth to the ISS is cheaper goes well beyond ridiculous. I don't think you could use an entire megabyte of bandwidth a month over SMS.
During the time of the YouTube acquisition, it was often discussed that they might have done it in order to set precedents for copyright laws and other distribution-related stuff (net neutrality, etc.) since Google has better lawyers than YouTube could have hoped to afford at the time. Theory being that if Youtube was sued, they wouldn't have the funding to fight unfair charges and a precedent would be set against them and other providers of free content; whereas with Google backing them they'd have the funding and/or legal team to win and have it go in their favor. It sucks that our court system favors who has the better lawyers and not what's actually in the law books, but that's life.
Skype, on the other hand, was just a stupid choice by eBay. But you can't expect much different from a company that's founded around the very concept of bad buying decisions.
It's as anti-competitive as trading in your used car when buying a new vehicle.
Chances are that if a student is bright enough to reverse-engineer their network protocols in order to cheat, s/he should be passing anyways. Doubly so if the password is "pencil" and we soon find ourselves on the brink of WWIII.
But in all seriousness, their client-server auth protocols are such a long-tail problem compared to people alt-tabbing over to Wikipedia that it's pretty much irrelevant. Less so for interacting with the admin interface, but they're probably using something a bit more transactional than a giant blob of XML, and I'd like to think that teachers would notice if someone goes from failing to straight-A student overnight.
Don't get me wrong... I just finished a massive rant about the importance of security elsewhere. But it's not like there's money or bombs on the other side of the connection, just test grades.
Well, about half of the discussions that I had during my middle and high school career regarding careers involved discussing how crappy teachers' pay is - not a terribly inviting way to get new people into the field. However, a teachers pay structure that's more of a meritocracy rather than looking for a cell on a table of years of service and level of education (this was how it was done at my HS; I don't know about anywhere else) would certainly give an incentive to be a better teacher - outside of the fundamental flaw of a meritocracy in that it brings out the worst in people as they try to cheat the system. Not really an easy problem to solve, but it's not insurmountable. If nothing else, I still see it as overall being more productive than systems structured around equality and political correctness - all teachers are NOT equally skilled, and should not be compensated as such.
The cause of the issue doesn't stop it from being a perfectly valid issue. Obviously it means we need to go about addressing said issue in a different way, but it doesn't invalidate an observation.
There are of course exceptions to any generalization, but stereotypes and generalizations exist BECAUSE the observed trait is accurate sufficiently often. When you're dealing with statistical sample sizes measured in millions or tens of millions, you can draw some pretty accurate results.
Yes, correlation is not causation, but that's completely irrelevant to the discussion. If you're drawing conclusions from the results of the ENTIRE standardized testing results from one year and notice that (all other things being equal) one race scores consistently higher than another, it's perfectly valid to use those results in a discussion however unfair those results seem.
Battery life, and the paper-like display. They also tend to be a hell of a lot thinner.
Not enough to sell me on one (I mostly listen to audiobooks anyways), but the market definitely exists.
That's not Facebook's fault. They offer you the controls to lock down your profile as much or as little as you want. Half of my Facebook friends I've never met and we're only playing a couple of games together online; they go in my "games" friend list on FB and have access to precisely none of my personal information. What information I've made public was done so intentionally, mostly to try and get a little extra Google juice.
You can flag just about any content on Facebook as inappropriate -especially photos and videos. Presumably only flagged content is reviewed at all. They are dealing with billions of photos after all.
assholes will eventually leek [sic] ... screw it ... black hole ... get out quickly
Looks like long-term involvement in the porn industry has a negative impact on your diction as well.
Actually, last I checked, Qik is only available on jailbroken phones, and they're... I wouldn't say mainstream but large enough to at least make it noteworthy. In their case it's because they had to hack some sort of crude video functionality into the built-in camera which you can't do through Apple's APIs rather than censorship.
They have complete control of the App Store. There's absolutely nothing stopping them from forcing developers to rate their apps for intended audience, much like the TV ratings (Y, Y7, 14, MA, with the D,S,L,V flags) or video games. It allows them to still disallow outright porn while flagging potentially-offensive software appropriately.
Because some nitwit will come by with an infected thumb drive which will grab files and post them to some server the next time it's on an internet-enabled machine.
Microsoft put itself in that situation. Safari and Firefox (and I'd assume Opera, I honestly don't know a damn thing about it) render to the same standards, plus support some sort of conditional stuff for upcoming standards (see: -moz-border-radius; -webkit-border-radius. Also note that they have slightly different syntaxes right now since the standard isn't finalized). As time moves forward they've come to also follow additional, newer standards, but that doesn't present an issue for backwards compatibility.
IE6 and IE7 both fail to render according to standards correctly, as we all well know. That means that on the corporate side, if you have apps that have been designed around this lack of standards-adherence, your stuff may well break in a future version as the browser suddenly follows the standards that it once ignored. Thankfully IE8 includes its fallback "compatibility" mode which will render standards-compliant sites according to standards*, and will use fallback modes for sites that don't adhere to the standards. This does a fantastic job eliminating that "will my app break if I make this upgrade?" concern, which is the primary reason that would stop corporate upgrades.
As far as home users that haven't upgraded yet - it's relatively safe to assume that most of these users never upgrade anything (despite many being security patches, etc) due to indifference, rather than avoidance. I'd bet a very large portion of home IE6 installs are on XP SP2 or earlier, with a number of unpatched security vulnerabilities. They probably disabled auto updates because they were annoyed by the dialog boxes and have been unknowingly sending out zombified spam for years.
*In my testing, this has always been the case, except for a select few newer CSS properties. As all of these add a little polish to the page but don't in any way affect layout (text-shadow, -X-box-shadow, -X-border-radius, @font-face, etc), this is fully a non-issue. Javascript libraries completely eliminate cross-browser scripting issues (through their own hacks as-needed, I expect), so it's not even on my radar as a concern.
What sort of SSB apps even exist for Windows? I'm aware of Fluid.app on OS X, but that uses the default system rendering engine, which is whatever version of Safari you have installed (well, technically the version of Webkit that your install of Safari uses, which might as well be the same thing). AFAIK, doing the same thing on Windows would be based off the currently installed version of IE; I'd assume that packaging IE6 in a Windows SSB would violate some sort of redistribution clause in the EULA. You'd be ok with Webkit or Gecko as both are open-source, but if your site ran properly in either of those rendering engines then you wouldn't have this problem in the first place.