Office 2010 To Enter BETA Next Month
"The latest version of the Office suite will be available for testing in November."
Published: 21st October 2009 | Source: CNET |
Microsoft Office 2010
Microsoft announced yesterday that it will be releasing a public test version of the latest office suite - Office 2010, in November. A limited preview of the suite was released in July, the full version is expected for release in 2010, obviously.
Microsoft, making the announcement at its SharePoint conference, also detailed some of the features of the next version of its portal software, which will also enter beta next month. The new version, SharePoint 2010, includes Office's Ribbon user interface as well as enhanced support for video, audio and Silverlight. Programmers will also be able develop Sharepoint sites using the next version of the company's Visual Studio, which is going into a second beta this week.
SharePoint is an important product for Microsoft as it is one of the company's fastest growing large businesses. Last year it brought in more than $1.3 billion in revenue, up 20 percent from the prior year.
"SharePoint 2010 is the biggest and most important release of SharePoint to date," CEO Steve Ballmer said in a statement. "When paired with Microsoft Office 2010, SharePoint 2010 will transform efficiency by connecting workers across a single collaboration platform for business."
Discuss in our Forums.
Most Recent Comments
it's just as deathwish pointed out
as data is deleted, the cells aren't actually erased. the next time the drive wants to write data to those same cells/blocks they have to be erased first before being written to again, causing extra write latency.
TRIM improves this by running after the delete command, queries the volume bitmap, sees data marked for discard and discards it.
as data is deleted, the cells aren't actually erased. the next time the drive wants to write data to those same cells/blocks they have to be erased first before being written to again, causing extra write latency.
TRIM improves this by running after the delete command, queries the volume bitmap, sees data marked for discard and discards it.
My bad, updated the article :)
Thanks for that.
Thanks for that.
Just bought a Vertex earlier today, only a 30GB one but will be alright for now until I can buy another for RAID0. Have it just for OS for now, but this firmware is perfectly timed for Windows 7 next week :D
it's just as deathwish pointed out
as data is deleted, the cells aren't actually erased. the next time the drive wants to write data to those same cells/blocks they have to be erased first before being written to again, causing extra write latency.
TRIM improves this by running after the delete command, queries the volume bitmap, sees data marked for discard and discards it.
That sounds pretty inefficient.
Is that something to do with the intergrity check of the controller or something ?
The matter that the data in a location was $009e0f50, then needs to be made $4c4f4c21, in theory, shouldn't require zero filling b4 hand.
Can u turn the discard thing off to speed things up ?
The root cause of the issue is that SSD drives do not know which blocks are truly in use and which are free. While the file system on the SSD will maintain an in-use list, SSDs don't understand file systems, and cannot access this list. This causes trouble in two places:
SSDs can write 4KB blocks at a time, but only delete 512KB blocks. Since the drive does not know which 4k blocks are still in use if they have been written to previously, each write requires a 512KB read-erase-modify-write cycle
That is crazy.
it's just how things work with current SSDs m8
you can disable TRIM in Windows7 (fsutil behavior set disabledeletenotify 1)... but why bother
TRIM happens after deletion and you don't even notice it
and it can't be too inefficient if these ssds rape plain mech. hdds
you can disable TRIM in Windows7 (fsutil behavior set disabledeletenotify 1)... but why bother
TRIM happens after deletion and you don't even notice it
and it can't be too inefficient if these ssds rape plain mech. hdds
Just found out SSD's in RAID cant use TRIM!! :( Not the best and need to get it sorted!
More than that, the more I read up on the tech behind ssds, the more I'm inclined to believe they filled a room full of monkeys to design them.
It's not as simple as memory allocation on memory chips.
It's not as simple as memory allocation on memory chips.
and i'm sure you could do better too huh?
Who knows, maybe.
What u tend to find more and more these days is tech/industry is being led, initially by thoughts of cash, but following that teams of "IT" or "engineer" people who, quite honestly, u wouldn't trust to do anything if u absolutely needed to.
Being as there are such controllers out there that can saturate an IDE channel by using a card loaded with SATA drives, raiding them and taking the cpu work away from the pc, e.g. the XFX revo64 - the makers of which went bust.
U can take the theory on 1 hand that ur using, or can be using, memory chips - which on the face of it aren't that expensive. There does already exist pci(e) card that u can load with memory dimms and use as an "ssd". This is taking files as they would appear on a regular hard drive and as opposed to using magnetic media in which to store them, u'r using memory. Inherently an old fashioned ram-drive (a harddrive mounted in memory space, tech of which has been around for decades) - u can't get faster r/w than that - ever - (or atleast ur bound by ur OS).
These of which hold problems of which I am not aware. If u like u can load files into memory locations and use them as if they're on a drive. No complications and the OS's interpretation is the only thing that holds u back in terms of access.
Why can't u take the same tech, mount the memory in style that is like the current SSD frame ? 64g u can get smaller than ur thumbnail. Flash drives show this. The size ratio, in terms of physical size, isn't great. 10x thumbnails and u have 640g (roughly). Throw in a controller and a SATA interface and away u go. Limitations are the OS and the SATA channel.
How to allocate files ? Use a table like the FAT on a traditional harddrive. Instead of sector locations on platters, use memory locations.
U write, u have memory to put stuff in, allocating the parts to the table. U delete, u remove the allocation. If ur being forensic or paranoid, u can zero fill the memory - as a choice.
Limitations ? Certainly not 4kb, using the ram-disk mentality, there is no difference to the OS, it sees it as a regular drive. The controller on the drive handles the difference between platter locations and memory locations.
The latter part there -really- is the main difference between using memory for drivespace and magnetic media.
Keep everything else the same and ur not governed by filesystem limitations, or lack of a filesystem. Track location = memory location. Other than that, the OS thinks it's a normal hdd.
I don't honestly see why they're stumbling on issues that are their own creation by invention.
Computer people > IT people.
What u tend to find more and more these days is tech/industry is being led, initially by thoughts of cash, but following that teams of "IT" or "engineer" people who, quite honestly, u wouldn't trust to do anything if u absolutely needed to.
Being as there are such controllers out there that can saturate an IDE channel by using a card loaded with SATA drives, raiding them and taking the cpu work away from the pc, e.g. the XFX revo64 - the makers of which went bust.
U can take the theory on 1 hand that ur using, or can be using, memory chips - which on the face of it aren't that expensive. There does already exist pci(e) card that u can load with memory dimms and use as an "ssd". This is taking files as they would appear on a regular hard drive and as opposed to using magnetic media in which to store them, u'r using memory. Inherently an old fashioned ram-drive (a harddrive mounted in memory space, tech of which has been around for decades) - u can't get faster r/w than that - ever - (or atleast ur bound by ur OS).
These of which hold problems of which I am not aware. If u like u can load files into memory locations and use them as if they're on a drive. No complications and the OS's interpretation is the only thing that holds u back in terms of access.
Why can't u take the same tech, mount the memory in style that is like the current SSD frame ? 64g u can get smaller than ur thumbnail. Flash drives show this. The size ratio, in terms of physical size, isn't great. 10x thumbnails and u have 640g (roughly). Throw in a controller and a SATA interface and away u go. Limitations are the OS and the SATA channel.
How to allocate files ? Use a table like the FAT on a traditional harddrive. Instead of sector locations on platters, use memory locations.
U write, u have memory to put stuff in, allocating the parts to the table. U delete, u remove the allocation. If ur being forensic or paranoid, u can zero fill the memory - as a choice.
Limitations ? Certainly not 4kb, using the ram-disk mentality, there is no difference to the OS, it sees it as a regular drive. The controller on the drive handles the difference between platter locations and memory locations.
The latter part there -really- is the main difference between using memory for drivespace and magnetic media.
Keep everything else the same and ur not governed by filesystem limitations, or lack of a filesystem. Track location = memory location. Other than that, the OS thinks it's a normal hdd.
I don't honestly see why they're stumbling on issues that are their own creation by invention.
Computer people > IT people.
CSS Valid
What does slow them down then?