I disagree. I consider Xen to be a kernel which other kernels are modified to run inside of, it is just a guest kernel making requests(read system calls) to a hypervisor(a special sort of kernel) that then translates it into requests to the host kernel. But mostly I feel this way because of the way I/O is handled in Xen is very much unlike the way VMware does it (go find my resume, I used to be an ESX developer at VMware).
A Xen guest runs its own kernel, with its own scheduler, network and block device subsystems, and filesystems. A VMware guest runs its own kernel, with its own scheduler, its own network and block device subsystems, and filesystems.
So what if Xen and VMware provide different mechanisms for running guest OSes and providing I/O? The same end result is achieved. In either case, guest OSes are isolated from other guest OSes and communicate via block/SCSI and network interfaces, and the guest OS runs some sort of network, block, or SCSI drivers to communicate.
BSD Jails are just a more Unix way of virtualizing a set of processes than Xen is. Xen requires an entire kernel to encapsulate the virtualization, BSD jails do not. In my opinion that is where they differ the most, but that difference is almost unimportant.
Userland containers (jail, VZ, Zones) use one kernel with one scheduler, one set of syscalls, one set of drivers, etc. Different containers may see a different network devices and filesystems, and may only see their own processes, but they're all running under one kernel that is aware of everything and limits the processes belong to each container to that container's namespace.
Most open source licenses say that as long as you don't modify the source, you don't have to contribute.
I'm not aware of any notable open-source license that requires those who modify the code to contribute their changes to the project; I'm only aware of licenses that require those who modify the code to distribute the modified source code to anyone they distribute the binary to. This is an important distinction. Those who modify code don't have to send their changes to the project maintainer/author or distribute it on the public Internet.
No, it appears there are significant technical differences - such as the inclusion of QuickPath and triple channel on 1366 and an integrated PCI-e controller on 1156. I wouldn't want an inefficient desktop because I had to use a socket with an excessively high bandwidth link.
i5 systems will be much cheaper - turns out that they won't have QuickPath at all, but will have an integrated PCI-e controller instead. This should allow for cheaper/simpler system boards. I think this will lead to lower power use as well.
LGA 1156 wil replace LGA 775 as the mainstream socket. And LGA 1366 won't take over as the mainstream desktop socket when all the CPUs are well over $100 and there are no chipsets with integrated graphics available.
LGA 1366 is intended for servers, workstations, and high-end gaming PCs. LGA 1156 will be the mainstream
desktop socket.
What's the difference? IIRC, LGA 1366 has a tripe-channel memory controller and support for dual CPUs (via another QuickPath link). LGA 1156 has dual-channel memory support with support for only one CPU.
The desktop CPU for LGA 1156 will be called Core i5.
Microsoft alone has several major and radically different GUI APIs, and there are several common third party ones in addition to that.
Windows has Win32. Things like MFC are simply abstractions on top of Win32. And the Win32 API has evolved since the early 90s - yet remains backwards compatible. A programmer can use any abstraction he likes, but the core Win32 API it uses is has remained consistent. A Win32 binary works across all compatible systems - there is no need to compile separate binaries for Windows 2000, Windows 7, etc. Compare to Linux, where using binary software not compiled specifically for each distribution is often discouraged...
See THIS is the problem. Not the fact that's included and that they don't include any other browser bla bla bla. The problem is how IE is integrated into the OS. That should be what the EU is trying to attack.
IE is not integrated into the OS, but the rendering engine (Trident) is part of the system. This is the approach used by KDE and OS X. Different GNOME/Gtk+ applications seem to do different things - but this appears to be typical open source fragmentation.
In OS X, WebKit is used by many applications. Remove the Safari application and WebKit is still there. Many iPhone applications also make use of WebKit.
That list, which is old, represents the 3rd party plugins which are bundled with iTunes by default. The SDK allows anyone to develop their own plugin.
I am not aware of any SDK that allows prorgrammers to develop an actual sync plugin for iTunes. Many applications use the iTunes COM/AppleScript interfaces to access iTunes library information and provide their own sync implementation. A real iTunes plugin would mean that third-party devices would appear in iTunes when plugged in and users would have the same interface as seen by Apple devices (according to the features supported by that device.)
Practical alternatives: Less general education and more specialized education. Most people who are diagnosed with ADHD have a certain field that they really care about and can really excel in, be it woodworking, computers, certain branches of science, history, etc. Our education system does not let students really customize what works for them. An ADHD student who really wants to be a welder and is amazing at welding isn't going to care too much about things that aren't related to welding such as history. That student then does poorly in history. Put that student in a shop class and they will do amazing. We try to have far too generic classes that are mandated in education, allow students to pick what they want to be in and learn that rather than things that they don't care about and the ADHD program will slowly fade away.
And how do you know this? Have you performed extensive studies or gathered any data?
This phenomenom you describe is not listed in the DSM-IV TR at all.
Yet, on Dell and HP's sites, it's easy to buy a server without any operating system. In fact, this seems to be the default on at least some of their servers.
OS choices offered by Dell and/or HP include SLES, RHEL, Windows, XenServer, ESXi, and Solaris.
That being said...while linux boxes and their GUI/Windowing systems can crash like any program can, it usually doesn't rile up the Linux users as badly as the MS Windows user, since on Linux, the Windowing system is running on top of and separate from the OS really. On linux, if your Xwindows or windows managers crashes, no big deal, you usually don't have to bring the whole system down to get it back up and started.
Many of the X.org/XFree86 crashes I've experienced have resulted in the entire system locking up (mainly with Intel and ATI GPUs.)
I've had quite a few graphics driver crashes in Windows as well, once again with Intel and ATI, but very few that crashed the entire system in Windows Vista. Instead, Vista restarts the driver and the session keeps on going. I've had one situation where the ATI driver caused the entire system to crash - when I was using hardware decoding to play back a corrupted H.264 video stream.
Windows Vista also has the ability to change/upgrade the display driver without losing the session - this is how Remote Desktop works.
As for OS X... I have had a few kernel panics caused by the ATI driver.
If you have an app that runs on OS 9, you can run that in classic mode (which I believe they stopped including for leopard, but I'm not sure), and that takes us back to 1999.
Classic was dropped in 10.5 and only works on PowerPC, anyway. So, as long as you have a 3+ year old Mac and are running an older version of the operating system...
Of course, if you stick with 10.4, you won't be able to run lots of newer programs... which commonly require 10.5.
Just to play devil's advocate, linux runs any X11 app and that goes back decades and decades (e.g., nethack is from 1985).
And if a program from the 80s can be compiled on a modern GNU/Linux system, it can be compiled for many systems - Windows (with SFU/SUA or Cygwin), OS X, BSD, Solaris... And X servers are available for all of those operating systems as well.
The problem is that it actually is an example that the ambiguity does not exist. This is quite clearly a bug in OpenOffice, it is quite obvious that the vast majority of programs, including Microsoft's own, do the expected thing. There are only TWO results he or anybody found, in searching two dozen programs: the way Microsoft does it, and a BUG in ONE program, OpenOffice!
The standard does not specify any formula syntax/semantics. The behavior of every ODF 1.1 implementation's formulas is not specified by the standard, because no such specification for formulas exists in the standard.
OO.o's implementation does not matter here because there is no standard for it to implement.
No specification for the syntax/semantics used by a forumla is defined in the ODF 1.1 standard. Instead, "Every formula should begin with a namespace prefix specifying the syntax and semantics used within the formula". Consequently, any ODF 1.1 implementation that has defined some syntax and semantics for a formula has implemented something extra that isn't part of the standard.
OpenOffice.org operating differently compared to other ODF implementations has nothing to do with Microsoft's implementation of ODF itself - it is an example to illustrate the ambiguity of ODF 1.1 formulas.
ODF 1.1 compliant spreadsheet implementations can have completely different formula syntax/semantics; the standard allows this and does not specify any standard syntax/semantics. And this is what happened.
Once completed, ODF 1.2 should solve this problem.
Interoperability in this case means, hell, what the dictionary says interoperability means: a way for different implementations of an office document so that they can be opened in others.
Microsoft is not required to and did not claim to be interoperable with non-standard implementations of ODF in Office 2007 SP2. They are claiming to be compliant with and interoperate with standard implementations of ODF 1.1.
Microsoft ALREADY HAD a viable, compliant AND interoperable implementation. In THIS ONE, they CHOSE to NOT interoperate.
NOT implementing interoperability in this instance has NOTHING to do with the standard: the part which they broke is NOT IN THE SPEC.
Microsoft is claiming to implementing the ODF standard - this is what they said they were going to do, and the ODF standard is what governments are mandating. Governments are not mandating an OO.o compatible implementation of ODF with nonstandard functionality, nor they are mandating an OO.o compatible implementation of the not-yet-finished ODF 1.2 format (which is used by OO.o 3).
How can someone break an implementation of a speficiation by not implementing functionality not in the specification?
"interoperability" in this case means looking at the other implementations of the ODF standard and looking at their nonstandard behavior. The nonstandard behavior varies between different versions. The latest version of hte most popular implementation does not even target the latest published standard.
They should be nailed to the wall by antitrust bodies all over the world.
Microsoft has been criticized for ignoring standards for years... Wouldn't it be hypocrtical for a government to prosecute Microsoft for implementing the published standard mandated by that government?
Microsoft is saying "The Oxford and American English Dictionaries disagree on the definition of a few words and don't define every possible word that will ever be invented. Therefore will write all our text in Klingon".
The definition of "standard" in this context has never been under dispute by anyone except for you and a few others on sites like Slashdot. In the context of something like the POSIX, ANSI C, or JPEG standards, the "standard" refers to the published specifications by the organization responsible for the standard - not the non-standard behavior of the most popular implementation, or the common ways in which the standard is broken by various implementations.
You are missing one ENORMOUS detail: the formulas ARE defined, they are defined by Open Office and every other ODF user as "do what Excel does" (to be pendantic they are "do what Excel does when set to a locale that uses commas as the decimal point").
"Do what Excel does" is not the behavior specified by the latest published standard, and "do it however Open Office does it" is not the behavior specified in the published standard either.
People have been sacrificing standards compliance for years in order to be compatible with someone else's exisitng nonstandard implementation. (In many cases, the nonstandard implementation was Microsoft's.) Now Microsoft is actually following the published standard, and everyone complains because it doesn't ignore the standard in the same way other applications ignore it...
Umm, yeah, if there were four open source programs that already implemented it that way and could be used as references and if every other implementation of that version of the standard in existence including Mozilla's other browser.
Standards do not work that way. Implementing something in a way contrary to the standard is not following the standard, no matter how many other (partial/noncompliant) implementations of the standard do the same thing.
That's what reference implementations are for. All your arguments boil down to MS not being able to complete the same task a half dozen smaller companies already did, while MS has code that works licensed such that they can copy and paste it in. I see no excuse.
And which "reference" implementation fully implements ODF 1.1 in a way that interoperates with other software?
Microsoft is following the published ODF 1.1 standard. "The nonstandard way that OpenOffice.org and a lot of applications do it" is not a standard.
And yet no other company or even hobbyist project had trouble implementing it, just MS. Do you really think they're that incompetent?
Other companies do have trouble implementing the standard. Having to "copy OpenOffice.org's nonstandard activity" means they are either not strictly implementing the standard or implementing added functionality not covered in the standard (that is, nonstandard functionality.)
MS is expected to have a standards-compliant implementation ODF 1.1, not one that emulates some other implementation's non-standard behaviors. People tend to get upset when Microsoft ignores or doesn't fully implement standards. OpenOffice.org 3's implementation of the not-yet finalized ODF 1.2 standard is not a published standard. "ODF 1.1+proprietary extras" is not a standard, either.
Microsoft said they were going to implement the published standard ODF 1.1, and this is what they claimed to have done. They did not say they were going to implement OpenOffice.org's specific way of using ODF with its nonstandard behavior. They did not say they were going to implement the (not finalized) ODF 1.2 as used by OpenOffice.org 3.
But it's clear an precise enough that it worked for everyone else and there are multiple working open source implementations, one of which they can literally copy and paste from and which they helped fund the creation of and probably have full rights to it even if it wasn't BSD licensed. Sorry, that argument doesn't fly either.
No, it just means that there are other implementations that behave similarly to OpenOffice.org.
Demanding that Microsoft implements the ambiguous / not standard parts of OO.o's ODF in the same way that OO.o does is sort of like demanding that Mozilla implements all the ambiguous / not standard parts of MS's HTML/CSS rendering implementation. Or demanding that Apple modify OS X's kernel so it implements the same syscalls as Linux instead of implementing POSIX, because Linux is the most popular operating system used to run programs that target POSIX.
Of course, with ODF, 1+2=1. ODF 1.1 is broken, and there is nothing that can be done to make a fully standards-compliant ODF 1.1 implementation without filling in the gaps somehow. Apparently, OO.o 1-2 uses a nonstandard forumla implementation and OO.o 3 writes to the not yet finished ODF 1.2 standard.
Apple's stance appears to be, right or wrong, that Java on the desktop and mobile devices is no longer the best way to develop and deploy software, and thus, they've allowed the Java implementation in OS X to grow long in the tooth, and have outright declined to port it to the iPhone/iPod Touch OS.
Regarding Java on mobile devices: The BlackBerry uses Java extensively, and for the functionality the two devices have in common, my BlackBerry manages to be faster and more stable than my iPhone. The BlackBerry has about half the RAM and a slower CPU. Simple things like loading the calculator, notes, or settings applications take at least a second on the iPhone, whereas on the BlackBerry they load nearly instantly. And applications on the BlackBerry can multitask... so the messaging application never closes at all.
Even if speeding itself does not *cause* an accident it *does* make the consequences worse.
And does this have any relation to the problem of speed limits, which some people follow as posted, some people use as a suggestion, and some people ignore?
Would you rather drive on a road with 80% of traffic traveling at 75-80 mph or a road with half of the cars driving at 60 mph and half driving at 75 mph?
(1)yeah, even review. VLC has some HD problems, which are ffmpeg related as I understand [google.com], and may show up on other Linux/OSS players. My i7/GTX280/6GB RAM was choking on a Hitachi made 1080p H.264 demo yesterday using VLC (on Windows). OTOH, AVCHD 21MB seems to be fine straight out of the camera, FWIW.
At one point I got better results with 1080p H.264 using MPC-HC in Windows in VMware Fusion than I did using VLC (OS X). With MPC-HC in VMware, the video played continously at 20-24 fps with tearing, whereas VLC simply stopped rendering video when the decoder couldn't keep up.
Slashdot Mirror
A Xen guest runs its own kernel, with its own scheduler, network and block device subsystems, and filesystems. A VMware guest runs its own kernel, with its own scheduler, its own network and block device subsystems, and filesystems.
So what if Xen and VMware provide different mechanisms for running guest OSes and providing I/O? The same end result is achieved. In either case, guest OSes are isolated from other guest OSes and communicate via block/SCSI and network interfaces, and the guest OS runs some sort of network, block, or SCSI drivers to communicate.
Userland containers (jail, VZ, Zones) use one kernel with one scheduler, one set of syscalls, one set of drivers, etc. Different containers may see a different network devices and filesystems, and may only see their own processes, but they're all running under one kernel that is aware of everything and limits the processes belong to each container to that container's namespace.
I'm not aware of any notable open-source license that requires those who modify the code to contribute their changes to the project; I'm only aware of licenses that require those who modify the code to distribute the modified source code to anyone they distribute the binary to. This is an important distinction. Those who modify code don't have to send their changes to the project maintainer/author or distribute it on the public Internet.
No, it appears there are significant technical differences - such as the inclusion of QuickPath and triple channel on 1366 and an integrated PCI-e controller on 1156. I wouldn't want an inefficient desktop because I had to use a socket with an excessively high bandwidth link.
i5 systems will be much cheaper - turns out that they won't have QuickPath at all, but will have an integrated PCI-e controller instead. This should allow for cheaper/simpler system boards. I think this will lead to lower power use as well.
LGA 1156 wil replace LGA 775 as the mainstream socket. And LGA 1366 won't take over as the mainstream desktop socket when all the CPUs are well over $100 and there are no chipsets with integrated graphics available.
LGA 1366 is intended for servers, workstations, and high-end gaming PCs. LGA 1156 will be the mainstream
desktop socket.
What's the difference? IIRC, LGA 1366 has a tripe-channel memory controller and support for dual CPUs (via another QuickPath link). LGA 1156 has dual-channel memory support with support for only one CPU.
The desktop CPU for LGA 1156 will be called Core i5.
Windows has Win32. Things like MFC are simply abstractions on top of Win32. And the Win32 API has evolved since the early 90s - yet remains backwards compatible. A programmer can use any abstraction he likes, but the core Win32 API it uses is has remained consistent. A Win32 binary works across all compatible systems - there is no need to compile separate binaries for Windows 2000, Windows 7, etc. Compare to Linux, where using binary software not compiled specifically for each distribution is often discouraged...
Firefox 3 didn't compile in RHEL/CentOS 4 with the shipped versions of libraries - and RHEL 4 is from 2005.
IE is not integrated into the OS, but the rendering engine (Trident) is part of the system. This is the approach used by KDE and OS X. Different GNOME/Gtk+ applications seem to do different things - but this appears to be typical open source fragmentation.
In OS X, WebKit is used by many applications. Remove the Safari application and WebKit is still there. Many iPhone applications also make use of WebKit.
KDE has KHTML, used by Konqueror.
I am not aware of any SDK that allows prorgrammers to develop an actual sync plugin for iTunes. Many applications use the iTunes COM/AppleScript interfaces to access iTunes library information and provide their own sync implementation. A real iTunes plugin would mean that third-party devices would appear in iTunes when plugged in and users would have the same interface as seen by Apple devices (according to the features supported by that device.)
It takes Emacs 30 seconds to open a 40 MB file?!
With an editor using memory mapped file access, any file should open instantly (as long as it fits in the address space).
In Visual Studio 2008, I can open a 40 MB file in well under half a second - and it's loading the entire file into RAM!
And how do you know this? Have you performed extensive studies or gathered any data?
This phenomenom you describe is not listed in the DSM-IV TR at all.
Yet, on Dell and HP's sites, it's easy to buy a server without any operating system. In fact, this seems to be the default on at least some of their servers.
OS choices offered by Dell and/or HP include SLES, RHEL, Windows, XenServer, ESXi, and Solaris.
Many of the X.org/XFree86 crashes I've experienced have resulted in the entire system locking up (mainly with Intel and ATI GPUs.)
I've had quite a few graphics driver crashes in Windows as well, once again with Intel and ATI, but very few that crashed the entire system in Windows Vista. Instead, Vista restarts the driver and the session keeps on going. I've had one situation where the ATI driver caused the entire system to crash - when I was using hardware decoding to play back a corrupted H.264 video stream.
Windows Vista also has the ability to change/upgrade the display driver without losing the session - this is how Remote Desktop works.
As for OS X... I have had a few kernel panics caused by the ATI driver.
Classic was dropped in 10.5 and only works on PowerPC, anyway. So, as long as you have a 3+ year old Mac and are running an older version of the operating system...
Of course, if you stick with 10.4, you won't be able to run lots of newer programs... which commonly require 10.5.
And if a program from the 80s can be compiled on a modern GNU/Linux system, it can be compiled for many systems - Windows (with SFU/SUA or Cygwin), OS X, BSD, Solaris... And X servers are available for all of those operating systems as well.
The standard does not specify any formula syntax/semantics. The behavior of every ODF 1.1 implementation's formulas is not specified by the standard, because no such specification for formulas exists in the standard.
OO.o's implementation does not matter here because there is no standard for it to implement.
No specification for the syntax/semantics used by a forumla is defined in the ODF 1.1 standard. Instead, "Every formula should begin with a namespace prefix specifying the syntax and semantics used within the formula". Consequently, any ODF 1.1 implementation that has defined some syntax and semantics for a formula has implemented something extra that isn't part of the standard.
OpenOffice.org operating differently compared to other ODF implementations has nothing to do with Microsoft's implementation of ODF itself - it is an example to illustrate the ambiguity of ODF 1.1 formulas.
ODF 1.1 compliant spreadsheet implementations can have completely different formula syntax/semantics; the standard allows this and does not specify any standard syntax/semantics. And this is what happened.
Once completed, ODF 1.2 should solve this problem.
Microsoft is not required to and did not claim to be interoperable with non-standard implementations of ODF in Office 2007 SP2. They are claiming to be compliant with and interoperate with standard implementations of ODF 1.1.
The ODF converter developers chose to do what OpenOffice.org does.
Microsoft is claiming to implementing the ODF standard - this is what they said they were going to do, and the ODF standard is what governments are mandating. Governments are not mandating an OO.o compatible implementation of ODF with nonstandard functionality, nor they are mandating an OO.o compatible implementation of the not-yet-finished ODF 1.2 format (which is used by OO.o 3).
How can someone break an implementation of a speficiation by not implementing functionality not in the specification?
"interoperability" in this case means looking at the other implementations of the ODF standard and looking at their nonstandard behavior. The nonstandard behavior varies between different versions. The latest version of hte most popular implementation does not even target the latest published standard.
Microsoft has been criticized for ignoring standards for years... Wouldn't it be hypocrtical for a government to prosecute Microsoft for implementing the published standard mandated by that government?
The definition of "standard" in this context has never been under dispute by anyone except for you and a few others on sites like Slashdot. In the context of something like the POSIX, ANSI C, or JPEG standards, the "standard" refers to the published specifications by the organization responsible for the standard - not the non-standard behavior of the most popular implementation, or the common ways in which the standard is broken by various implementations.
"Do what Excel does" is not the behavior specified by the latest published standard, and "do it however Open Office does it" is not the behavior specified in the published standard either.
People have been sacrificing standards compliance for years in order to be compatible with someone else's exisitng nonstandard implementation. (In many cases, the nonstandard implementation was Microsoft's.) Now Microsoft is actually following the published standard, and everyone complains because it doesn't ignore the standard in the same way other applications ignore it...
Standards do not work that way. Implementing something in a way contrary to the standard is not following the standard, no matter how many other (partial/noncompliant) implementations of the standard do the same thing.
And which "reference" implementation fully implements ODF 1.1 in a way that interoperates with other software?
Microsoft is following the published ODF 1.1 standard. "The nonstandard way that OpenOffice.org and a lot of applications do it" is not a standard.
Other companies do have trouble implementing the standard. Having to "copy OpenOffice.org's nonstandard activity" means they are either not strictly implementing the standard or implementing added functionality not covered in the standard (that is, nonstandard functionality.)
MS is expected to have a standards-compliant implementation ODF 1.1, not one that emulates some other implementation's non-standard behaviors. People tend to get upset when Microsoft ignores or doesn't fully implement standards. OpenOffice.org 3's implementation of the not-yet finalized ODF 1.2 standard is not a published standard. "ODF 1.1+proprietary extras" is not a standard, either.
Microsoft said they were going to implement the published standard ODF 1.1, and this is what they claimed to have done. They did not say they were going to implement OpenOffice.org's specific way of using ODF with its nonstandard behavior. They did not say they were going to implement the (not finalized) ODF 1.2 as used by OpenOffice.org 3.
No, it just means that there are other implementations that behave similarly to OpenOffice.org.
Demanding that Microsoft implements the ambiguous / not standard parts of OO.o's ODF in the same way that OO.o does is sort of like demanding that Mozilla implements all the ambiguous / not standard parts of MS's HTML/CSS rendering implementation. Or demanding that Apple modify OS X's kernel so it implements the same syscalls as Linux instead of implementing POSIX, because Linux is the most popular operating system used to run programs that target POSIX.
Of course, with ODF, 1+2=1. ODF 1.1 is broken, and there is nothing that can be done to make a fully standards-compliant ODF 1.1 implementation without filling in the gaps somehow. Apparently, OO.o 1-2 uses a nonstandard forumla implementation and OO.o 3 writes to the not yet finished ODF 1.2 standard.
Regarding Java on mobile devices:
The BlackBerry uses Java extensively, and for the functionality the two devices have in common, my BlackBerry manages to be faster and more stable than my iPhone. The BlackBerry has about half the RAM and a slower CPU. Simple things like loading the calculator, notes, or settings applications take at least a second on the iPhone, whereas on the BlackBerry they load nearly instantly. And applications on the BlackBerry can multitask... so the messaging application never closes at all.
AWT/Swing may be limited to X11, but SWT applications can still use Carbon (or Cocoa using the in-development version.)
And does this have any relation to the problem of speed limits, which some people follow as posted, some people use as a suggestion, and some people ignore?
Would you rather drive on a road with 80% of traffic traveling at 75-80 mph or a road with half of the cars driving at 60 mph and half driving at 75 mph?
Did you try a DirectShow player that uses ffmpeg, such as Media Player Classic Homecinema?
At one point I got better results with 1080p H.264 using MPC-HC in Windows in VMware Fusion than I did using VLC (OS X). With MPC-HC in VMware, the video played continously at 20-24 fps with tearing, whereas VLC simply stopped rendering video when the decoder couldn't keep up.