... to just buy an AppleTV and install boxee on that? Really, why do you need an actual Linux box, when Apple's hardware is custom built for exactly this sort of thing?
I have tried boxee on my MythTV box, and it's got potential - but it's also got quite a few rough edges (and given its nature, there's no guarantee that what works today will keep working tomorrow). Oh, and the Linux version won't work with Netflix or ABC, either.
I've been running MythTV for years, and you really don't need anything fancy here. Ext3 is the default filesystem on almost every Linux distribution for a reason - there's no commonly used Linux filesystem that's more widely supported, and except in some odd edge cases you won't find anything that outperforms it by a meaningful margin.
That said, if you're in a position to run ZFS, you really should. My current home setup has a Solaris x86 box with 5 500 GB drives in a raidz array mounted via NFS on the MythTV box, and it works marvelously. The downside, of course, is that there's no in-kernel implementation for Linux, so you really need a separate box. I've used raidz with both FreeBSD and Solaris, and you can't go wrong in either case.
I suppose if you were really nuts you could do this all on a single machine: run Xen on your Linux box, export the raw devices to Solaris or FreeBSD running in a DomU, run ZFS there, and then export back to the Dom0 which would also run MythTV. I'd probably just use Ext3, though:)
Can you elabourate on that statement for a clueless newbie (when it comes to these farking wireless standards at least:)
Are you saying that people are claiming that it doesn't work with ATT but are using 3G sims when a GSM sim is required?
No - "3G SIMs" are designed to support both GSM and UMTS, so this device should be able to access AT&T's 2G network with a "3G SIM." Some people are reporting that this device is not working with such a SIM, and that's a legitimate problem - but it has nothing to do with "3G networks" as the summary implies, since the device can't operate on 3G networks to begin with.
OpenMoko still has problems with some 3G networks, including AT&T.
This claim is misleading - the device has no UMTS radio, so of course AT&T's 3G network isn't supported. What's really happening is that some people who have "3G" SIM cards are having trouble accessing AT&Ts GSM network.
I have to wonder - just what is it doing that you feel rebooting every few days is the proper remedy?
I run OpenWRT and never reboot my device (save when a power outage forces me to), but even stock firmware should be quite stable for most people. Rebooting the device is not normal, and either your device is defective or you have another problem elsewhere in your configuration (that's coincidentally fixed when you reboot the NAT device).
Nokia is in a tough spot here. They're still the market leader for smartphones world wide, but Windows Mobile has been biting into that for a while now, and Android is just around the corner. I can't help but equate Symbian to PalmOS - a technical jumble that's frustrating to develop for and nearly impossible to maintain, being attacked by rapidly growing and technically superior competitors.
In the case of Palm, they couldn't fix PalmOS *or* spool up a replacement in time, and they were thus relegated to Yet Another Windows Mobile vendor. I suppose Nokia is trying to avoid that fate by taking over Symbian and throwing enough resources at it to keep it alive and moving forward, but that can't be easy. Nokia also seems to take the Sun view of open source: if you can no longer make money from something, open source it for good will. That's fine, but given how crufty Symbian is and how many alternatives there are now I'm not sure what good that code is going to do anybody.
Either way, I'm sure the other Symbian partners are happy to have it off their hands. Android is clearly the superior platform in the near-term, and divorcing themselves from Symbian allows them to focus their efforts there. Despite that, it's clear that Nokia is resisting Android - maybe to differentiate themselves from the competitors, maybe just to prevent obsoleting all of their existing Symbian resources - but it will be interesting to see if they can ultimately avoid becoming Yet Another Andriod Vendor themselves.
Keep in mind that ruby and PHP are essentially contemporaries - they've both been in real use for over a decade. By most measures, one would think of them as being "mature" technologies, and yet we still see bugs like this crop up in both languages. I think it just goes to show - while selecting a "mature" technology has its advantages, it will not make you immune to problems.
For what it's worth, this appears to be a flaw in the official ruby interpreter. That's a big deal, of course, but just so you know: most people who speak the praises of ruby are talking about the structure of the language, not necessarily the implementation of the interpreter itself. There are alternate implementations of the ruby interpreter that are generally considered to be "better" than Matz's in many ways.
For those of you who haven't figured out why this is dumb yet, consider playing a board game with friends, and having one of your more affluent friends pulling out his wallet and offering other players real money for their monopoly money.
It's not really analogous - Monopoly is 1) a directly competitive game with 2) a well-defined endpoint that is 3) measured largely by the amount of currency players posses.
In contrast, MMOs, while containing elements of competition, are not generally "won" or "lost," rather they contain content that is "consumed." There is no endpoint, as there's always the potential to consume something else, and success isn't even measured by how much gold one has. It's really defined by a series of successes and failures - in many ways, that's a similar paradigm to real life.
Furthermore, the quantity of gold accumulated in an MMO is almost always proportional to the time spent in the game - in the typical system, time is effectively converted to in-game wealth. I don't think being unemployed will help you win a game of Monopoly, but it will sure give you a lot more time to acquire MMO wealth.
It's hard to find a workable analogy that makes game currency exchange actually look bad, because it's basically just an extension of the way our real economy operates. You have a product that people want, they have a resource they can exchange for that product. People who buy the product with real-world money have simply earned a different, but equally (or more) valuable, resource outside of the game.
It destroys Opera (8.5, apparently) on my n800, to the point that the site is pretty much unusable once I try to load a story. I much prefer Discussion2 in general, but I hope there continues to be a way to disable it if there's no way to work around the Opera issues.
Ultimately the audience for this book is somewhat narrow; folks interested in the history of the Massive genre will find this interesting, and avid players of EverQuest or UO have probably at least heard of the guild. Certainly, for members of The Syndicate, they now have something guaranteed to wig out their family members. "There's a book about your little club?" Outside of novelty value, I'm not sure there's a lot of other people who might find this text enlightening.
Ah, but don't forget librarians interested in talking to "digital natives"!
Though it's not exactly spawned by the internet, it's the result of heavy wifi penetration, which I suppose is close enough. Things like "blog" at least describe something that didn't exactly have a useful term before (though why "weblog" itself needed to be shortened, I can't really understand), but "wireline" is essentially a synonym for "wired" or "plugged in" or "cabled," which is used only in marketing materials since it sounds more like "wireless" (and "wireless" is just, you know, way cool).
If that's not bad enough, wireline is actually a real term with a distinct existing meaning - so not only is its new usage unnecessary, it's also incompatible with the old usage. Hooray!
The only good thing about "wireline" is that it hasn't really penetrated the web 2.0 consciousness yet, and it seems to still be mostly a marketing term. For example, I haven't heard about it much in the blogosphere, it hasn't started showing up in mashups, and it isn't appearing in many tag clouds. I can only guess the technocrati haven't finished working out the folksonomy for it yet - but once they do, you can bet it'll spread quickly on all those social networking sites the kids love these days...
That's a good thought, but I think you miss the mark. Data Direct was created as a response to the various screen scrapers that existed before it - scrapers which had to pull down and parse entire HTML documents instead of simply using compact, per-user xml feeds. This service was intended to reduce total bandwidth use, and as far as I'm aware it succeeded at doing so.
It's possible that there has been a shift in management and that this history lesson was forgotten, but if their intention is to save bandwidth it seems doubtful that this is a good way to do so.
I use my n800 in almost exactly the same manner. When your phone is just a phone, you can pick up one that's really small and cheap and keep it tucked away with you at all times, using it as a bluetooth modem should you need to use the n800 and are out of wifi range.
At first, I thought the n800's non-phoneness would bother me - but I've quickly come to appreciate the fact that it is a distinct device. If I go cycling or kayaking, for example, it's very nice to have a phone, but I generally have no need for the features of the n800. Since the two devices are separable, I can easily take the small, cheap phone with me into the "danger zone" and leave the n800 safely behind.
I had originally hoped to find a device that reasonably combined the functionality of the n800 with that of a phone (the Nokia N95 comes very close, but its lack of US 3G killed it for me, and the iPhone's limitations are too severe), but I'm fairly happy with my current solution at roughly half the price. Maybe, if prices drop enough, the platform is opened up, the device is freed from AT&T's network, and the feature set catches up a bit with Nokia devices, the iPhone will be a contender for my next purchase - but right now, I too am enjoying the flexibility of the cheapo phone + n800 combo.
ZFS is licensed under the CDDL, and hence cannot (legally) be integrated into the Linux kernel. It's possible to get ZFS running on Linux systems *right now* using FUSE, but unless/until Sun's licensing terms change (note - they may) what you ask for is not possible.
As other posters have mentioned, LVM + MD is a fairly good solution. It's clearly not as easy to work with as ZFS, but it's adequate for most needs and is extensively documented.
The original post specifically mentions iSCSI and OpenSolaris, presumably because iSCSI is a required feature and OpenSolaris (or Solaris Express) is where you need to look to get it.
More generally speaking, iSCSI is a pretty integral feature in the whole network storage game, and in that area Solaris (and as an extension ZFS) isn't even competing yet.
If you can get by without iSCSI, you're in a much better position as you can run Solaris 10 11/06 instead, which is a supportable OS and in my experience generally rock solid. But again, if you're looking for feature parity with the big appliance players, it's just not there yet.
You don't need to "continually upgrade," but there are several reasons that this setup in particular is going to be fairly volitile.
Most notably, if you're going with OpenSolaris or Solaris Express now, you'll at the very least want to move to Solaris 10 (or 11) when the actual product's feature set catches up with the "beta" version.
The key thing to remember here is that this isn't a typical Solaris install, where you're running something that's rock solid and proven that you can run largely unmodified for 5-10 years - this is a bleeding edge setup using the absolutely latest (largely untested) features that are still likely to evolve over time. You'll find new bugs, and you'll probably want to have them fixed. New features will appear, and you'll probably want to take advantage of them.
Basically, OpenSolaris is to Solaris 10 as Fedora Core is to RHEL. By running the OS, you acknowledge that your system is not a final product, and that certain things may not be in their final state. For something like home use or small office use, that's probably acceptable - but if you want to be able to maintain it, and you have any hopes for commercial support, you're going to need to upgrade.
Hence my note that the single-user/reboot process isn't *really* required, but if you look at Sun's patch documentation that's what it almost invariably says.
I don't want to sound critical of ZFS or Solaris - that's not my intent. Solaris is a wonderful operating environment, and ZFS is an incredibly powerful filesystem and volume manager. However, the fact of the matter is that implementing and administering an appliance-based solution is almost invariably going to be simpler and better supported, especially since ZFS is a relatively immature technology - there are some things you just flat out can't do yet, and some things you can't do as easily.
If the question is "Does ZFS Obsolete Expensive NAS/SANs?" the answer is clearly "not yet." At some point that may be a more difficult question to answer - ZFS is amazingly powerful despite being very young, and along with Solaris itself it continues to rapidly improve in important ways.
It's no NetApp - yet.
One thing to realize is that iSCSI target isn't even in Solaris proper yet - you have to run Solaris Express or OpenSolaris for the functionality. That may be fine for some people, but it's a deal-breaker for most companies - you're really going to place all those TB of data on a system that's basically unsupported? I'm sure Sun would lend you a hand for enough money, but running essentially a pre-release version of Solaris is a non-starter where real business is concerned. Even when iSCSI target makes it into Solaris 10 - which should be in the next release - are you really comfortable running critical services off of essentially the first release of the technology?
Furthermore, while ZFS is amazingly simple to manage in comparison to any other UNIX filesystem/volume manager, it still requires you to know how to properly administer a Solaris box in order to use it. Even GUI-centric sysadmins are generally able to muddle through the interface on a Filer, but ZFS comes with a full-fledged OS that requires proper maintenance. Your Windows admins may be fine with a NetApp - especially with all that marvelous support you get from them - but ask them to maintain a Solaris box and you're asking for trouble. Not to mention, since it's a real, general purpose server OS, you'll have to maintain patches just like you do on the rest of your servers - and the supported method for patching Solaris is *still* to drop to single user mode and reboot afterwards (yes, I know that's not necessarily *required*).
Also, "zfs send" is no real replacement for snapmirrors. And while ZFS snapshots are functionally equivalent to NetApp snapshots, there is no method for automatic creation and management of them - it's up to the admin to create any snapshotting scheme you want to implement.
Don't get me wrong - I love ZFS and I use it wherever it makes sense to do so. It may even be acceptable as a "poor man's Filer" right now, assuming you don't need iSCSI or any of the more advanced features of a NetApp. In fact, it's a really great solution for home or small office fileservers, where you just need a bunch of network storage on the cheap - assuming, of course, that you already have a Solaris sysadmin at your home or small office.
Just don't fool yourself, Filer it ain't - at least not yet.
Slashdot Mirror
... to just buy an AppleTV and install boxee on that? Really, why do you need an actual Linux box, when Apple's hardware is custom built for exactly this sort of thing?
I have tried boxee on my MythTV box, and it's got potential - but it's also got quite a few rough edges (and given its nature, there's no guarantee that what works today will keep working tomorrow). Oh, and the Linux version won't work with Netflix or ABC, either.
I've been running MythTV for years, and you really don't need anything fancy here. Ext3 is the default filesystem on almost every Linux distribution for a reason - there's no commonly used Linux filesystem that's more widely supported, and except in some odd edge cases you won't find anything that outperforms it by a meaningful margin.
That said, if you're in a position to run ZFS, you really should. My current home setup has a Solaris x86 box with 5 500 GB drives in a raidz array mounted via NFS on the MythTV box, and it works marvelously. The downside, of course, is that there's no in-kernel implementation for Linux, so you really need a separate box. I've used raidz with both FreeBSD and Solaris, and you can't go wrong in either case.
I suppose if you were really nuts you could do this all on a single machine: run Xen on your Linux box, export the raw devices to Solaris or FreeBSD running in a DomU, run ZFS there, and then export back to the Dom0 which would also run MythTV. I'd probably just use Ext3, though :)
Can you elabourate on that statement for a clueless newbie (when it comes to these farking wireless standards at least :)
Are you saying that people are claiming that it doesn't work with ATT but are using 3G sims when a GSM sim is required?
No - "3G SIMs" are designed to support both GSM and UMTS, so this device should be able to access AT&T's 2G network with a "3G SIM." Some people are reporting that this device is not working with such a SIM, and that's a legitimate problem - but it has nothing to do with "3G networks" as the summary implies, since the device can't operate on 3G networks to begin with.
OpenMoko still has problems with some 3G networks, including AT&T.
This claim is misleading - the device has no UMTS radio, so of course AT&T's 3G network isn't supported. What's really happening is that some people who have "3G" SIM cards are having trouble accessing AT&Ts GSM network.
I have to wonder - just what is it doing that you feel rebooting every few days is the proper remedy?
I run OpenWRT and never reboot my device (save when a power outage forces me to), but even stock firmware should be quite stable for most people. Rebooting the device is not normal, and either your device is defective or you have another problem elsewhere in your configuration (that's coincidentally fixed when you reboot the NAT device).
Nokia is in a tough spot here. They're still the market leader for smartphones world wide, but Windows Mobile has been biting into that for a while now, and Android is just around the corner. I can't help but equate Symbian to PalmOS - a technical jumble that's frustrating to develop for and nearly impossible to maintain, being attacked by rapidly growing and technically superior competitors.
In the case of Palm, they couldn't fix PalmOS *or* spool up a replacement in time, and they were thus relegated to Yet Another Windows Mobile vendor. I suppose Nokia is trying to avoid that fate by taking over Symbian and throwing enough resources at it to keep it alive and moving forward, but that can't be easy. Nokia also seems to take the Sun view of open source: if you can no longer make money from something, open source it for good will. That's fine, but given how crufty Symbian is and how many alternatives there are now I'm not sure what good that code is going to do anybody.
Either way, I'm sure the other Symbian partners are happy to have it off their hands. Android is clearly the superior platform in the near-term, and divorcing themselves from Symbian allows them to focus their efforts there. Despite that, it's clear that Nokia is resisting Android - maybe to differentiate themselves from the competitors, maybe just to prevent obsoleting all of their existing Symbian resources - but it will be interesting to see if they can ultimately avoid becoming Yet Another Andriod Vendor themselves.
Keep in mind that ruby and PHP are essentially contemporaries - they've both been in real use for over a decade. By most measures, one would think of them as being "mature" technologies, and yet we still see bugs like this crop up in both languages. I think it just goes to show - while selecting a "mature" technology has its advantages, it will not make you immune to problems.
For what it's worth, this appears to be a flaw in the official ruby interpreter. That's a big deal, of course, but just so you know: most people who speak the praises of ruby are talking about the structure of the language, not necessarily the implementation of the interpreter itself. There are alternate implementations of the ruby interpreter that are generally considered to be "better" than Matz's in many ways.
It's not really analogous - Monopoly is 1) a directly competitive game with 2) a well-defined endpoint that is 3) measured largely by the amount of currency players posses.
In contrast, MMOs, while containing elements of competition, are not generally "won" or "lost," rather they contain content that is "consumed." There is no endpoint, as there's always the potential to consume something else, and success isn't even measured by how much gold one has. It's really defined by a series of successes and failures - in many ways, that's a similar paradigm to real life.
Furthermore, the quantity of gold accumulated in an MMO is almost always proportional to the time spent in the game - in the typical system, time is effectively converted to in-game wealth. I don't think being unemployed will help you win a game of Monopoly, but it will sure give you a lot more time to acquire MMO wealth.
It's hard to find a workable analogy that makes game currency exchange actually look bad, because it's basically just an extension of the way our real economy operates. You have a product that people want, they have a resource they can exchange for that product. People who buy the product with real-world money have simply earned a different, but equally (or more) valuable, resource outside of the game.
It destroys Opera (8.5, apparently) on my n800, to the point that the site is pretty much unusable once I try to load a story. I much prefer Discussion2 in general, but I hope there continues to be a way to disable it if there's no way to work around the Opera issues.
Ultimately the audience for this book is somewhat narrow; folks interested in the history of the Massive genre will find this interesting, and avid players of EverQuest or UO have probably at least heard of the guild. Certainly, for members of The Syndicate, they now have something guaranteed to wig out their family members. "There's a book about your little club?" Outside of novelty value, I'm not sure there's a lot of other people who might find this text enlightening.
Ah, but don't forget librarians interested in talking to "digital natives"!
"wireline."
Though it's not exactly spawned by the internet, it's the result of heavy wifi penetration, which I suppose is close enough. Things like "blog" at least describe something that didn't exactly have a useful term before (though why "weblog" itself needed to be shortened, I can't really understand), but "wireline" is essentially a synonym for "wired" or "plugged in" or "cabled," which is used only in marketing materials since it sounds more like "wireless" (and "wireless" is just, you know, way cool).
If that's not bad enough, wireline is actually a real term with a distinct existing meaning - so not only is its new usage unnecessary, it's also incompatible with the old usage. Hooray!
The only good thing about "wireline" is that it hasn't really penetrated the web 2.0 consciousness yet, and it seems to still be mostly a marketing term. For example, I haven't heard about it much in the blogosphere, it hasn't started showing up in mashups, and it isn't appearing in many tag clouds. I can only guess the technocrati haven't finished working out the folksonomy for it yet - but once they do, you can bet it'll spread quickly on all those social networking sites the kids love these days...
That's a good thought, but I think you miss the mark. Data Direct was created as a response to the various screen scrapers that existed before it - scrapers which had to pull down and parse entire HTML documents instead of simply using compact, per-user xml feeds. This service was intended to reduce total bandwidth use, and as far as I'm aware it succeeded at doing so.
It's possible that there has been a shift in management and that this history lesson was forgotten, but if their intention is to save bandwidth it seems doubtful that this is a good way to do so.
I use my n800 in almost exactly the same manner. When your phone is just a phone, you can pick up one that's really small and cheap and keep it tucked away with you at all times, using it as a bluetooth modem should you need to use the n800 and are out of wifi range.
At first, I thought the n800's non-phoneness would bother me - but I've quickly come to appreciate the fact that it is a distinct device. If I go cycling or kayaking, for example, it's very nice to have a phone, but I generally have no need for the features of the n800. Since the two devices are separable, I can easily take the small, cheap phone with me into the "danger zone" and leave the n800 safely behind.
I had originally hoped to find a device that reasonably combined the functionality of the n800 with that of a phone (the Nokia N95 comes very close, but its lack of US 3G killed it for me, and the iPhone's limitations are too severe), but I'm fairly happy with my current solution at roughly half the price. Maybe, if prices drop enough, the platform is opened up, the device is freed from AT&T's network, and the feature set catches up a bit with Nokia devices, the iPhone will be a contender for my next purchase - but right now, I too am enjoying the flexibility of the cheapo phone + n800 combo.
ZFS is licensed under the CDDL, and hence cannot (legally) be integrated into the Linux kernel. It's possible to get ZFS running on Linux systems *right now* using FUSE, but unless/until Sun's licensing terms change (note - they may) what you ask for is not possible.
As other posters have mentioned, LVM + MD is a fairly good solution. It's clearly not as easy to work with as ZFS, but it's adequate for most needs and is extensively documented.
The original post specifically mentions iSCSI and OpenSolaris, presumably because iSCSI is a required feature and OpenSolaris (or Solaris Express) is where you need to look to get it.
More generally speaking, iSCSI is a pretty integral feature in the whole network storage game, and in that area Solaris (and as an extension ZFS) isn't even competing yet.
If you can get by without iSCSI, you're in a much better position as you can run Solaris 10 11/06 instead, which is a supportable OS and in my experience generally rock solid. But again, if you're looking for feature parity with the big appliance players, it's just not there yet.
You don't need to "continually upgrade," but there are several reasons that this setup in particular is going to be fairly volitile.
Most notably, if you're going with OpenSolaris or Solaris Express now, you'll at the very least want to move to Solaris 10 (or 11) when the actual product's feature set catches up with the "beta" version.
The key thing to remember here is that this isn't a typical Solaris install, where you're running something that's rock solid and proven that you can run largely unmodified for 5-10 years - this is a bleeding edge setup using the absolutely latest (largely untested) features that are still likely to evolve over time. You'll find new bugs, and you'll probably want to have them fixed. New features will appear, and you'll probably want to take advantage of them.
Basically, OpenSolaris is to Solaris 10 as Fedora Core is to RHEL. By running the OS, you acknowledge that your system is not a final product, and that certain things may not be in their final state. For something like home use or small office use, that's probably acceptable - but if you want to be able to maintain it, and you have any hopes for commercial support, you're going to need to upgrade.
Hence my note that the single-user/reboot process isn't *really* required, but if you look at Sun's patch documentation that's what it almost invariably says.
I don't want to sound critical of ZFS or Solaris - that's not my intent. Solaris is a wonderful operating environment, and ZFS is an incredibly powerful filesystem and volume manager. However, the fact of the matter is that implementing and administering an appliance-based solution is almost invariably going to be simpler and better supported, especially since ZFS is a relatively immature technology - there are some things you just flat out can't do yet, and some things you can't do as easily.
If the question is "Does ZFS Obsolete Expensive NAS/SANs?" the answer is clearly "not yet." At some point that may be a more difficult question to answer - ZFS is amazingly powerful despite being very young, and along with Solaris itself it continues to rapidly improve in important ways.
It's no NetApp - yet. One thing to realize is that iSCSI target isn't even in Solaris proper yet - you have to run Solaris Express or OpenSolaris for the functionality. That may be fine for some people, but it's a deal-breaker for most companies - you're really going to place all those TB of data on a system that's basically unsupported? I'm sure Sun would lend you a hand for enough money, but running essentially a pre-release version of Solaris is a non-starter where real business is concerned. Even when iSCSI target makes it into Solaris 10 - which should be in the next release - are you really comfortable running critical services off of essentially the first release of the technology? Furthermore, while ZFS is amazingly simple to manage in comparison to any other UNIX filesystem/volume manager, it still requires you to know how to properly administer a Solaris box in order to use it. Even GUI-centric sysadmins are generally able to muddle through the interface on a Filer, but ZFS comes with a full-fledged OS that requires proper maintenance. Your Windows admins may be fine with a NetApp - especially with all that marvelous support you get from them - but ask them to maintain a Solaris box and you're asking for trouble. Not to mention, since it's a real, general purpose server OS, you'll have to maintain patches just like you do on the rest of your servers - and the supported method for patching Solaris is *still* to drop to single user mode and reboot afterwards (yes, I know that's not necessarily *required*). Also, "zfs send" is no real replacement for snapmirrors. And while ZFS snapshots are functionally equivalent to NetApp snapshots, there is no method for automatic creation and management of them - it's up to the admin to create any snapshotting scheme you want to implement. Don't get me wrong - I love ZFS and I use it wherever it makes sense to do so. It may even be acceptable as a "poor man's Filer" right now, assuming you don't need iSCSI or any of the more advanced features of a NetApp. In fact, it's a really great solution for home or small office fileservers, where you just need a bunch of network storage on the cheap - assuming, of course, that you already have a Solaris sysadmin at your home or small office. Just don't fool yourself, Filer it ain't - at least not yet.