> PS No, I don't work for Sun, and I'm not in bed with them. But > working for a LARGE company has taught me many things about > Bureaucracy, and two of those are: 1) Assume a lack of action before > an action (i.e., things tend *not* to happen in a bureaucracy), and 2) > if you can, pointing to a thing is almost always better than asking > for an unknown.
No, you misunderstand. We've tried so hard; that is no excuse. Perhaps this will teach them to be less opaque.
I think there are some times when Theo's style is dead on, like with the ipf filter. However, in this case it may not be the most constructive way to effect a change.
Well, in my job experience (small to midsize companies) those two jobs are effectively the same. You wear whatever hat is necessary to get what needs to be done, done.
So, if you want my advice I would say to get a job at a smaller company where you can easily wear multiple hats, grow your experience, experiment with technologies that *you* think can help your company instead of being stuck with dead-end technologies that some PHB mandated from on high. After designing and implementing a few successful projects you should be able to get a job anywhere.
If you're stuck in a larger-sized business, a good company will support your efforts in migrating to a different department. It's usually a win-win situation. You get to do what you want, the company gets to keep someone that they already trust and who knows much more about the company's specific operations than a new hire. If your boss won't help you switch departments, then a good HR person usually will.
Parachutes possible
on
Fanwing Planes?
·
· Score: 4, Interesting
I seem to remember a report of the first successful real-world use of a emergency parachute for light aircraft. A cessna-like plane had its engines cut own and the pilot was able to parachute his entire plane to safety.
Perhaps that is a valid solution for this fanwing bird.
I've been experimenting with Gigabit Ethernet lately.
The good news is that it's less expensive than you think. Decent cards are only marginally more expensive than good 100bT cards, and netgear now makes a reasonably prices 8port gigibit switch. It doesn't support jumbo frames but it's quite usuable for small networks.
The bad news is that I'm finding that gigabit ethernet doesn't deliver the performance you might expect using traditional network protocols. NFS in particular sees only modest gains, even when using nfsv3 and increasing the block sizes and tuning the kernel buffers/TCP options. I'm still showing bandwidth bottlenecks on the network when I should be seeing bandwidth bottlenecks on the disk array.
It would appear that something isn't scaling. Given that network benchmarking tools do show gigabit ethernet performing at a reasonable speed, it would appear that most "legacy" protocols are not architected to take advantage of it.
Nation A asks Microsoft to let it see source code, obstentatiously for development reasons, but actually because they wish to insure Nation A didn't put a back door in it, and also so they can put a back door in it themselves.
Maybe the problem is that the world doesn't need yet another proprietary instant messaging platform.
No offense, but IM is infrastructure that should be under control of a standards body, or at the very least open source and distributed, not jealously guarded by a bunch of companies each with their own extremely evil EULA.
Perhaps your customers rightly recognize this state of affairs. I know I do, and that's why I prefer Jabber for IM.
I and the people I work with purchase all kinds of linux software, from development tools to high-end graphics applications, to games. Perhaps your problem isn't linux, it's your product.
Does anyone know why they can't just point the Hubble telescope at the lunar landing sites and get a picture of the evidence?
Depends on if you're using native apps
on
Is Mac OS X Slow?
·
· Score: 3, Informative
My 700Mhz iBook running OSX 10.2 is quite snappy with all native apps, especially the ones I compile myself. It feels comparable to my 1.4Ghz Athlon running Redhat 8.0.
If you run MacOS 9 apps in compatibility mode, the feel is more sluggish, but that's to be expected. Emulation almost always degrades performance.
As another poster has already stated, you've done the right thing. Given the customer's requirements it looks like buying an off-the-shelf solution is the way to go.
Open source can be a win for some situations, such as when you want to do heavy integration, when your administrators are comfortable maintaining the app, when the application is easy enough to deal with that you don't need signficiant support, etc.
It's not the right choice in every scenario. You shouldn't sell a do-it-yourself kit to someone who wants a polished, fire-and-forget solution.
Re:Are you kidding?
on
Halloween VII
·
· Score: 3, Insightful
I can't speak for Ximian, but I was rather underimpressed with Red Hat 8--and I've never really even tried Linux before.
This is really incredulous to me.. I remember showing Redhat Linux to some friends, who had never known anything but windows and macintosh systems.
They were blown away. They were totally incredulous that such a distribution of OS, development tools, and large array of real applications was 100% Free and largely developed and maintained by worldwide communities of independent programmers.
If you are not completely astounded by this fact, then you have some serious entitlement issues to work out.
The fact that linux is better at some things than the MS operating systems and worse at others is insignificant in comparison.
Exactly what good would it do NVidia if they opened their sources so that ATI can copy it and have a "solid OpenGL feature set" like them?
What part of "all other things being equal" did you not read?
Having said that, I'd still rather see graphics board hardware vendors compete on the merits of their hardware, rather than make their drivers undebuggable and closed source.
Our application heavily uses the NVidia cards for specialized rendering, and as solid as their linux drivers are, they are not very solid. Our applications regularly crash their driver doing perfectly legal openGL calls. When this happens we get NO USEFUL DEBUGGING OUTPUT. Either X crashes, or the system hangs, with no logging, even if you supposedly enable logging in their driver options.
It is an arduous process to track down exactly what sequence of calls crashes their drivers, write an example app, and then send it in to NVidia to fix sometime in the next 2-4 months. It would be so much more helpful to see for ourselves where the problem is occuring. We've asked for drivers with better debug multiple times, but they won't provide any because of "IP Issues".
On top of all this, there's issues with them not properly supporting various kernels, their lack of official support for linux related questions (their community message board is useless for getting an answer to serious questions beyond installation), and the fact that you no longer have a single source for the linux kernel builds. On top of this you now have to deal with kernel tainting and all the irritation that causes.
I remember reading an article last year about The Weather Channel sponsoring a team to improve ATI's linux drivers. I think it's only a matter of time before other reasonably performing graphics cards offer good accellerated openGL drivers that ARE open source, and ship with the linux kernel. When that happens, there will be little reason for us to stick with closed source NV.
We've stopped using Rational products precisely because of the proprietary kernel driver issue.
There's nothing more irritating to me than than trying to shoehorn binary drivers into kernels they were inevitably not designed for.
My advice to you would be to do your proprietary driver in usermode, or put a small GPL'd driver in the kernel that then communicates to your proprietary code using a published, well defined interface.
Keep in mind, however, that all other things being equal using a proprietary software driver under linux puts you at a competitive disadvantage. If ATI's open source drivers had as solid an openGL feature set as NVidia's under linux, I'd switch in a second.
Why don't you move your proprietary IP into the firmware of your device and leave the driver open?
Why is slashdot running advertisements for proprietary products masquerading as stories?
One of the few things that differentiates this site from Ziff Davis crap is the emphasis on Free Software/Open Source.
yes yes, I realize there's some mozilla's technology that is being co-opted into this proprietary product, but is that really a newsworthy thing? What's next, press releases for products that use the BSD tcp/ip stack?
As an experiment I gave one of my spare computers to my technically adventurous folks a year ago, loaded up with Linux, tweaked to be as user friendly for their needs as I could make it without making absurd security tradeoffs. They already have a windows computer as a safety net to fall back on, so I'm not on the hook for desperate technical support:)
When they do call, it's sometimes because they are trying to do something that doesn't have a GUI admin tool, but more often it is simply a logistics problem of how to get file A into application B.
They were heavy Mac users who switched over to Windows during Apple's pre-OS8 bad period, so they are fluent with the graphical filebrowser tools. The graphical filebrowser is their filesystem tool of choice, and there's no sense in retraining them to use a terminal window which, while better at certain tasks, is much less pleasing to the eye and completely unintuitive.
So Nautilus is my friend, and I was very pleased to find out that under Redhat 8.0 Nautilus is now fast enough to use comfortably.
In many ways Nautilus is innovative, and pushes the envelope just as much if not more than Apple or MS. Automatic thumbnailing of images, hover-playback of music files, integration with a variety of high level network protocols make it a surprisingly powerful tool.
Don't discount the utility of these kinds of tools, both for CLI experts and newbies. There's a lot to like both technically and visually.
Nautilus lets my folks use Galeon, Evolution, Grip, XMMS, OpenOffice.org, the CD drive, and their USB keychain drive as a coherent whole system instead of a random assortment of disconnected parts. It's the visual glue.
For the record, they like Redhat 8.0 better than Windows 2000 for internet browsing and email, but prefer windows for financial apps like Quicken and opening up other people's MS Office docs.
It may very well be that the "average" Mac user is changing. Ever since OS X, I and other *nix folk have been enthusiasticly adopting the platform alongside our usual assortment of Linux/BSDs workstations. No GUI on the market can currently match OS X. The system is an absolute dream to work on, and for my budget the 14" ibook is the laptop of choice.
From this point of view, it is a great thing that I can now use OpenOffice.org on all my platforms!
Well, this seems like a disappointment. Although you could take the interview at face value, it looks like Chris wrote these responses with an eye toward paroll.
Not that I blame him, but it's too bad we couldn't fast forward a few years and ask him the same questions when he can speak more freely.
The Rio Volt's lack of Vorbis support is the only reason I haven't bought one.
If consumers demand hardware support for the format, someone will build it. If people want Ogg support, and all the freedoms that come with it, they should start using the format now and accept no substitutes.
Despite what the RIAA wants, they can only stay in business by selling products people want to buy.
It looks like a lot of people have already challenged your assertion that IDE is just as good as SCSI. However, no one brought up the particular issue that plagues my experience with IDE - hardware write caching.
Most modern IDE drives have write caching enabled by default. However, under every OS I've tested this configuration can lose data, even with a journaling filesystem. The problem is that the filesystem thinks that the data is successfully written to disk, but it's actually in the drive's cache buffer. If you lose power at the wrong moment, you lose that data. I've reproduced this problem with Western Digital, Seagate, and Maxtor 7200rpm 4MB buffer 80GB IDE drives under both Linux 2.4.X kernels and Microsoft 98/2000/XP platforms.
I've written in to each of those drive manufacturers and they have confirmed that the cache buffer isn't backed by some battery or other type of power reserve, and that data can be lost when power is removed.
Apparently this isn't an issue in SCSI land because SCSI drives respect a flush command, while some IDE drives do not.
The bottom line is that if you want a reliable system with IDE drives you need to disable write caching, which drastically increases disk access latency and results in reduced throughput for many tasks.
I'd love it if a kernel hacker can provide some more details as to why journaling filesystems can't forceably flush the IDE disk's buffer... I've found many older threads on the issue on the linux kernel list but haven't found any definitive resolution or action items recently.
As the situation stands now, my iozone benchmarks show a 15k RPM 80GB SCSI drive performing 2x to 3x better across all tests than a 7.2k RPM 80GB IDE drive with write caching disabled, DMA turned on, and all other hdparm options optimized for maximal performance. That is a pretty large difference. Yes, I did verify that the hdparm tuning options were working correctly.
And yes, the 3ware IDE RAID controllers have the exact same problem. They have an on-board raid cache, but it's not battery backed, so it is not a good idea to enable write caching in most cases. The 3ware cards are great and cheap, but they don't perform as well as their scsi equivalents.
Before someone tries to flame me, yes I have heard of a UPS, but for the machines I'm trying to protect I can't trust that the UPS will be properly maintained, not overloaded, strong enough to survive a long outage, or that the customer won't hit the power button themselves out of ignorance when they think that the system has "hung".
Redhat's unified desktop is a step forward. Since both desktop environments are customizable, users can still make them look and act any way they want. The choice is still there.
Now, the desktop environments will compete more on technical prowness than their default look, which is where the competition should be IMHO.
I hope that this decision helps unifiy the two desktop environmnents down the road.
You're right that it would be incorrect to flatly state that all VB apps suck.
HOWEVER, most VB apps do. It appears from my informal observations that there is a percentage of VB programmers without any formal training. Also, even large VB programs tend to be maintained by one person (or consultant) and not managed with source control or any eye towards future use. Blindly slapping together 3rd party toolkits and microsoft's solution of the month leads to bad products. Without an understanding of what is going on behind VB's veneer, it is impossible to correctly architect an application.
Just in the last year I've seen three major, multiyear database frontend products written in VB where the programmers had no understanding of fundamental issues such as managing concurrent transactions and encapsulating functionality behind sane interfaces.
This is annecdotal evidence, sure, but other people seem to have noticed it too. VB isn't a terrible language in an of itself, but many of applications produced with it are terrible. It's as if those with real coding talent moved on, and those who could not stuck with the platform and bet that no one would look at their code.
Eventually that kind of shortsighted judgement will bite you, even it the app appeared to work ok last week.
Slashdot Mirror
I find it difficult to sympathize with people who wish to keep academic journals locked away.
What I take great comfort in is that for "the only real option I have", OpenOffice.org is a damn fine one.
I think there are some times when Theo's style is dead on, like with the ipf filter. However, in this case it may not be the most constructive way to effect a change.
Well, in my job experience (small to midsize companies) those two jobs are effectively the same. You wear whatever hat is necessary to get what needs to be done, done.
So, if you want my advice I would say to get a job at a smaller company where you can easily wear multiple hats, grow your experience, experiment with technologies that *you* think can help your company instead of being stuck with dead-end technologies that some PHB mandated from on high. After designing and implementing a few successful projects you should be able to get a job anywhere.
If you're stuck in a larger-sized business, a good company will support your efforts in migrating to a different department. It's usually a win-win situation. You get to do what you want, the company gets to keep someone that they already trust and who knows much more about the company's specific operations than a new hire. If your boss won't help you switch departments, then a good HR person usually will.
I seem to remember a report of the first successful real-world use of a emergency parachute for light aircraft. A cessna-like plane had its engines cut own and the pilot was able to parachute his entire plane to safety.
Perhaps that is a valid solution for this fanwing bird.
I've been experimenting with Gigabit Ethernet lately.
The good news is that it's less expensive than you think. Decent cards are only marginally more expensive than good 100bT cards, and netgear now makes a reasonably prices 8port gigibit switch. It doesn't support jumbo frames but it's quite usuable for small networks.
The bad news is that I'm finding that gigabit ethernet doesn't deliver the performance you might expect using traditional network protocols. NFS in particular sees only modest gains, even when using nfsv3 and increasing the block sizes and tuning the kernel buffers/TCP options. I'm still showing bandwidth bottlenecks on the network when I should be seeing bandwidth bottlenecks on the disk array.
It would appear that something isn't scaling. Given that network benchmarking tools do show gigabit ethernet performing at a reasonable speed, it would appear that most "legacy" protocols are not architected to take advantage of it.
Nation A asks Microsoft to let it see source code, obstentatiously for development reasons, but actually because they wish to insure Nation A didn't put a back door in it, and also so they can put a back door in it themselves.
Maybe the problem is that the world doesn't need yet another proprietary instant messaging platform.
No offense, but IM is infrastructure that should be under control of a standards body, or at the very least open source and distributed, not jealously guarded by a bunch of companies each with their own extremely evil EULA.
Perhaps your customers rightly recognize this state of affairs. I know I do, and that's why I prefer Jabber for IM.
I and the people I work with purchase all kinds of linux software, from development tools to high-end graphics applications, to games. Perhaps your problem isn't linux, it's your product.
Yeah yeah, I wish there were a native alternative, but it works now.
Does anyone know why they can't just point the Hubble telescope at the lunar landing sites and get a picture of the evidence?
My 700Mhz iBook running OSX 10.2 is quite snappy with all native apps, especially the ones I compile myself. It feels comparable to my 1.4Ghz Athlon running Redhat 8.0.
If you run MacOS 9 apps in compatibility mode, the feel is more sluggish, but that's to be expected. Emulation almost always degrades performance.
Openoffice.org for MacOSX is quite nice, BTW.
As another poster has already stated, you've done the right thing. Given the customer's requirements it looks like buying an off-the-shelf solution is the way to go.
Open source can be a win for some situations, such as when you want to do heavy integration, when your administrators are comfortable maintaining the app, when the application is easy enough to deal with that you don't need signficiant support, etc.
It's not the right choice in every scenario. You shouldn't sell a do-it-yourself kit to someone who wants a polished, fire-and-forget solution.
I can't speak for Ximian, but I was rather underimpressed with Red Hat 8--and I've never really even tried Linux before.
This is really incredulous to me.. I remember showing Redhat Linux to some friends, who had never known anything but windows and macintosh systems.
They were blown away. They were totally incredulous that such a distribution of OS, development tools, and large array of real applications was 100% Free and largely developed and maintained by worldwide communities of independent programmers.
If you are not completely astounded by this fact, then you have some serious entitlement issues to work out.
The fact that linux is better at some things than the MS operating systems and worse at others is insignificant in comparison.
Exactly what good would it do NVidia if they opened their sources so that ATI can copy it and have a "solid OpenGL feature set" like them?
What part of "all other things being equal" did you not read?
Having said that, I'd still rather see graphics board hardware vendors compete on the merits of their hardware, rather than make their drivers undebuggable and closed source.
Our application heavily uses the NVidia cards for specialized rendering, and as solid as their linux drivers are, they are not very solid. Our applications regularly crash their driver doing perfectly legal openGL calls. When this happens we get NO USEFUL DEBUGGING OUTPUT. Either X crashes, or the system hangs, with no logging, even if you supposedly enable logging in their driver options.
It is an arduous process to track down exactly what sequence of calls crashes their drivers, write an example app, and then send it in to NVidia to fix sometime in the next 2-4 months. It would be so much more helpful to see for ourselves where the problem is occuring. We've asked for drivers with better debug multiple times, but they won't provide any because of "IP Issues".
On top of all this, there's issues with them not properly supporting various kernels, their lack of official support for linux related questions (their community message board is useless for getting an answer to serious questions beyond installation), and the fact that you no longer have a single source for the linux kernel builds. On top of this you now have to deal with kernel tainting and all the irritation that causes.
I remember reading an article last year about The Weather Channel sponsoring a team to improve ATI's linux drivers. I think it's only a matter of time before other reasonably performing graphics cards offer good accellerated openGL drivers that ARE open source, and ship with the linux kernel. When that happens, there will be little reason for us to stick with closed source NV.
We've stopped using Rational products precisely because of the proprietary kernel driver issue.
There's nothing more irritating to me than than trying to shoehorn binary drivers into kernels they were inevitably not designed for.
My advice to you would be to do your proprietary driver in usermode, or put a small GPL'd driver in the kernel that then communicates to your proprietary code using a published, well defined interface.
Keep in mind, however, that all other things being equal using a proprietary software driver under linux puts you at a competitive disadvantage. If ATI's open source drivers had as solid an openGL feature set as NVidia's under linux, I'd switch in a second.
Why don't you move your proprietary IP into the firmware of your device and leave the driver open?
Why is slashdot running advertisements for proprietary products masquerading as stories?
One of the few things that differentiates this site from Ziff Davis crap is the emphasis on Free Software/Open Source.
yes yes, I realize there's some mozilla's technology that is being co-opted into this proprietary product, but is that really a newsworthy thing? What's next, press releases for products that use the BSD tcp/ip stack?
Boo! Hiss!
As an experiment I gave one of my spare computers to my technically adventurous folks a year ago, loaded up with Linux, tweaked to be as user friendly for their needs as I could make it without making absurd security tradeoffs. They already have a windows computer as a safety net to fall back on, so I'm not on the hook for desperate technical support :)
When they do call, it's sometimes because they are trying to do something that doesn't have a GUI admin tool, but more often it is simply a logistics problem of how to get file A into application B.
They were heavy Mac users who switched over to Windows during Apple's pre-OS8 bad period, so they are fluent with the graphical filebrowser tools. The graphical filebrowser is their filesystem tool of choice, and there's no sense in retraining them to use a terminal window which, while better at certain tasks, is much less pleasing to the eye and completely unintuitive.
So Nautilus is my friend, and I was very pleased to find out that under Redhat 8.0 Nautilus is now fast enough to use comfortably.
In many ways Nautilus is innovative, and pushes the envelope just as much if not more than Apple or MS. Automatic thumbnailing of images, hover-playback of music files, integration with a variety of high level network protocols make it a surprisingly powerful tool.
Don't discount the utility of these kinds of tools, both for CLI experts and newbies. There's a lot to like both technically and visually.
Nautilus lets my folks use Galeon, Evolution, Grip, XMMS, OpenOffice.org, the CD drive, and their USB keychain drive as a coherent whole system instead of a random assortment of disconnected parts. It's the visual glue.
For the record, they like Redhat 8.0 better than Windows 2000 for internet browsing and email, but prefer windows for financial apps like Quicken and opening up other people's MS Office docs.
It may very well be that the "average" Mac user is changing. Ever since OS X, I and other *nix folk have been enthusiasticly adopting the platform alongside our usual assortment of Linux/BSDs workstations. No GUI on the market can currently match OS X. The system is an absolute dream to work on, and for my budget the 14" ibook is the laptop of choice.
From this point of view, it is a great thing that I can now use OpenOffice.org on all my platforms!
"It aint worth a dog
If it won't play my ogg."
doo-wop doo-wop doo-wop
I'm won't buy any digital audio hardware without Ogg Vorbis support!
Yes, but Redhat 8.0 somehow manages to make Nautilus fast. Now *that* is a mighty difficult desktop stunt to beat!
Well, this seems like a disappointment. Although you could take the interview at face value, it looks like Chris wrote these responses with an eye toward paroll.
Not that I blame him, but it's too bad we couldn't fast forward a few years and ask him the same questions when he can speak more freely.
The Rio Volt's lack of Vorbis support is the only reason I haven't bought one.
If consumers demand hardware support for the format, someone will build it. If people want Ogg support, and all the freedoms that come with it, they should start using the format now and accept no substitutes.
Despite what the RIAA wants, they can only stay in business by selling products people want to buy.
It looks like a lot of people have already challenged your assertion that IDE is just as good as SCSI. However, no one brought up the particular issue that plagues my experience with IDE - hardware write caching.
Most modern IDE drives have write caching enabled by default. However, under every OS I've tested this configuration can lose data, even with a journaling filesystem. The problem is that the filesystem thinks that the data is successfully written to disk, but it's actually in the drive's cache buffer. If you lose power at the wrong moment, you lose that data. I've reproduced this problem with Western Digital, Seagate, and Maxtor 7200rpm 4MB buffer 80GB IDE drives under both Linux 2.4.X kernels and Microsoft 98/2000/XP platforms.
I've written in to each of those drive manufacturers and they have confirmed that the cache buffer isn't backed by some battery or other type of power reserve, and that data can be lost when power is removed.
Apparently this isn't an issue in SCSI land because SCSI drives respect a flush command, while some IDE drives do not.
The bottom line is that if you want a reliable system with IDE drives you need to disable write caching, which drastically increases disk access latency and results in reduced throughput for many tasks.
I'd love it if a kernel hacker can provide some more details as to why journaling filesystems can't forceably flush the IDE disk's buffer... I've found many older threads on the issue on the linux kernel list but haven't found any definitive resolution or action items recently.
As the situation stands now, my iozone benchmarks show a 15k RPM 80GB SCSI drive performing 2x to 3x better across all tests than a 7.2k RPM 80GB IDE drive with write caching disabled, DMA turned on, and all other hdparm options optimized for maximal performance. That is a pretty large difference. Yes, I did verify that the hdparm tuning options were working correctly.
And yes, the 3ware IDE RAID controllers have the exact same problem. They have an on-board raid cache, but it's not battery backed, so it is not a good idea to enable write caching in most cases. The 3ware cards are great and cheap, but they don't perform as well as their scsi equivalents.
Before someone tries to flame me, yes I have heard of a UPS, but for the machines I'm trying to protect I can't trust that the UPS will be properly maintained, not overloaded, strong enough to survive a long outage, or that the customer won't hit the power button themselves out of ignorance when they think that the system has "hung".
Redhat's unified desktop is a step forward. Since both desktop environments are customizable, users can still make them look and act any way they want. The choice is still there.
Now, the desktop environments will compete more on technical prowness than their default look, which is where the competition should be IMHO.
I hope that this decision helps unifiy the two desktop environmnents down the road.
You're right that it would be incorrect to flatly state that all VB apps suck.
HOWEVER, most VB apps do. It appears from my informal observations that there is a percentage of VB programmers without any formal training. Also, even large VB programs tend to be maintained by one person (or consultant) and not managed with source control or any eye towards future use. Blindly slapping together 3rd party toolkits and microsoft's solution of the month leads to bad products. Without an understanding of what is going on behind VB's veneer, it is impossible to correctly architect an application.
Just in the last year I've seen three major, multiyear database frontend products written in VB where the programmers had no understanding of fundamental issues such as managing concurrent transactions and encapsulating functionality behind sane interfaces.
This is annecdotal evidence, sure, but other people seem to have noticed it too. VB isn't a terrible language in an of itself, but many of applications produced with it are terrible. It's as if those with real coding talent moved on, and those who could not stuck with the platform and bet that no one would look at their code.
Eventually that kind of shortsighted judgement will bite you, even it the app appeared to work ok last week.