dietmar - Developer IT

Jungledisk - choosing between Amazon S3 and Rackspace ?

- by Dietmar

Hi, jungledisk is owned by rackspace and offers an option to choose Amazon S3 which charges for traffic whereby if data is stored on rackspace, no charges for traffic. For a small company, to just backup files with jungle disk from ubuntu linux OS computers, i wonder what to choose. Commercial psychologically the price on traffic and the Amazon brand make it appear or maybe it is, of better quality than the cheaper Rackspace offer which is when it comes for just backing up ok ? but if its about backing up around 30 GB which updates from time to time, what would you consider a good choice ?

Read the article

APEX auf der DOAG2012

- by carstenczarski

Die DOAG2012, die im deutschsprachigen Raum wichtigste Konferenz für Oracle-Anwender steht vor der Tür. Vom 20. bis zum 22. November trifft sich die Oracle Community in Nürnberg. Und natürlich spielt auch Application Express eine wichtige Rolle auf der Konferenz: Insgesamt 26 Vorträge beschäftigen sich mit verschiedenen Aspekten der Anwendungsentwicklung mit Application Express. Hören Sie spannende Neuigkeiten vom APEX Development Team (Patrick Wolf, Marc Sewtz, Christian Neumüller) und von anderen, anerkannten APEX Experten aus dem deutschsprachigen Raum - mit Peter Raganitsch, Dietmar Aust oder Niels de Bruijn seien nur drei genannt. Wie im letzten Jahr haben Sie auch dieses Jahr wieder die Gelegenheit, den APEX Experten (und dem APEX Development Team) direkte Fragen zu stellen. Das APEX Experten Panel findet am ersten Konferenztag (20.11.) um 16:00 Uhr im Raum Hongkong statt. Wie im letzten Jahr bitten wir Sie, uns Ihre Fragen für das Panel hier einzureichen. Die Liste werden wir vor der Konferenz konsolidieren und an die APEX-Experten weitergeben, so dass alle Themen im Panel zur Sprache kommen können.

Read the article

Bahnbrechend und einsatzbereit: Oracle 12c In-Memory-Option Launch in Frankfurt

- by Anne Manke

Seit der Ankündigung der Oracle 12c In-Memory-Databankoption in San Francisco auf der Openworld im letzten Jahr, ist die DB Community gespannt, was diese bahnbrechende Technologie für Ad-hoc-Echtzeitanalysen von Live-Transaktionen, Data Warehousing, Reporting und Online Transaction Processing (OLTP) bringen wird. Die Messlatte liegt hoch, denn Larry Ellison verspricht mit der neuen 12c In-Memory-Option eine 100-fach schnellerer Verarbeitung von Abfragen bei Echtzeitanalysen für OLTP Prozesse oder Datawarehouses eine Verdoppelung der Transaktionsverarbeitung eine 100%ige Kompatibilität zu bestehenden Anwendungen Daten werden im Zeilenformat und Spaltenformat (In-Memory) abgelegt, und sind dabei aktiv und konsitstent Cloud-ready ohne Datamigration eine Ausweitung der In-Memory-basierten Abfrageprozesse auf mehrere Server Um nur einige Features zu nennen >> mehr Infos finden Sie hier! Abfragen werden mit der neuen 12c In-Memory-Datenbankoption schneller bearbeitet, als die Anfrage gestellt werden kann, so Larry Ellison. Am 17. Juni 2014 wird die 12c In-Memory auf einer exklusiven Launch-Veranstaltung in Frankfurt am Main vorgestellt. Auf der Agenda stehen Vorträge, Diskussionen und eine LiveDemo der In-Memory-Datenbankoption. Melden Sie sich jetzt an! Ort & Zeit: 17. Juni 2014, 9:30 - 15:15 Uhr in Radisson Blu Hotel (Franklinstrasse 65, 60486 Frankfurt am Main) Agenda 9:30 Registrierung 10:00 Begrüßung Guenther Stuerner, Vice President Sales Consulting, Oracle Deutschland (in deutscher Sprache) 10:15 Analystenvortrag Carl W. Olofson, Research Vice President, IDC (in englischer Sprache) 10:35 Keynote Andy Mendelsohn, Head of Database Development, Oracle (in englischer Sprache) 11:35 Podiumsdiskussion (in englischer Sprache): · Jens-Christian Pokolm, Postbank Systems AG · Andy Mendelsohn, Head of Database Development, Oracle · Carl W. Olofson, Research Vice President, IDC · Dr. Dietmar Neugebauer, Vorstandsvorsitzender, DOAG 12:30 Mittagessen 13:45 Oracle Database In Memory Option Perform – Manage – Live Demo Ralf Durben, Senior Leitender Systemberater, Oracle Deutschland (in deutscher Sprache) 14:30 In Memory – Revolution for your DWH – Real Time Datawarehouse – Mixed Workloads – Live Demo – Live Data Query Alfred Schlaucher, Senior Leitender Systemberater, Oracle Deutschland (in deutscher Sprache) 15:15 Schlusswort & Networking

Read the article

c++ std::ostringstream vs std::string::append

- by NickSoft

In all examples that use some kind of buffering I see they use stream instead of string. How is std::ostringstream and << operator different than using string.append. Which one is faster and which one uses less resourses (memory). One difference I know is that you can output different types into output stream (like integer) rather than the limited types that string::append accepts. Here is an example: std::ostringstream os; os << "Content-Type: " << contentType << ";charset=" << charset << "\r\n"; std::string header = os.str(); vs std::string header("Content-Type: "); header.append(contentType); header.append(";charset="); header.append(charset); header.append("\r\n"); Obviously using stream is shorter, but I think append returns reference to the string so it can be written like this: std::string header("Content-Type: "); header.append(contentType) .append(";charset=") .append(charset) .append("\r\n"); And with output stream you can do: std::string content; ... os << "Content-Length: " << content.length() << "\r\n"; But what about memory usage and speed? Especially when used in a big loop. Update: To be more clear the question is: Which one should I use and why? Is there situations when one is preferred or the other? For performance and memory ... well I think benchmark is the only way since every implementation could be different. Update 2: Well I don't get clear idea what should I use from the answers which means that any of them will do the job, plus vector. Cubbi did nice benchmark with the addition of Dietmar Kühl that the biggest difference is construction of those objects. If you are looking for an answer you should check that too. I'll wait a bit more for other answers (look previous update) and if I don't get one I think I'll accept Tolga's answer because his suggestion to use vector is already done before which means vector should be less resource hungry.

Read the article

C question: Padding bits in unsigned integers and bitwise operations (C89)

- by Anonymous Question Guy

I have a lot of code that performs bitwise operations on unsigned integers. I wrote my code with the assumption that those operations were on integers of fixed width without any padding bits. For example an array of 32 bit unsigned integers of which all 32 bits available for each integer. I'm looking to make my code more portable and I'm focused on making sure I'm C89 compliant (in this case). One of the issues that I've come across is possible padded integers. Take this extreme example, taken from the GMP manual: However on Cray vector systems it may be noted that short and int are always stored in 8 bytes (and with sizeof indicating that) but use only 32 or 46 bits. The nails feature can account for this, by passing for instance 8*sizeof(int)-INT_BIT. I've also read about this type of padding in other places. I actually read of a post on SO last night (forgive me, I don't have the link and I'm going to cite something similar from memory) where if you have, say, a double with 60 usable bits the other 4 could be used for padding and those padding bits could serve some internal purpose so they cannot be modified. So let's say for example my code is compiled on a platform where an unsigned int type is sized at 4 bytes, each byte being 8 bits, however the most significant 2 bits are padding bits. Would UINT_MAX in that case be 0x3FFFFFFF (1073741823) ? #include <stdio.h> #include <stdlib.h> /* padding bits represented by underscores */ int main( int argc, char **argv ) { unsigned int a = 0x2AAAAAAA; /* __101010101010101010101010101010 */ unsigned int b = 0x15555555; /* __010101010101010101010101010101 */ unsigned int c = a ^ b; /* ?? __111111111111111111111111111111 */ unsigned int d = c << 5; /* ?? __111111111111111111111111100000 */ unsigned int e = d >> 5; /* ?? __000001111111111111111111111111 */ printf( "a: %X\nb: %X\nc: %X\nd: %X\ne: %X\n", a, b, c, d, e ); return 0; } is it safe to XOR two integers with padding bits? wouldn't I XOR whatever the padding bits are? I can't find this behavior covered in C89. furthermore is the c var guaranteed to be 0x3FFFFFFF or if for example the two padding bits were both on in a or b would c be 0xFFFFFFFF ? same question with d and e. am i manipulating the padding bits by shifting? I would expect to see this below, assuming 32 bits with the 2 most significant bits used for padding, but I want to know if something like this is guaranteed: a: 2AAAAAAA b: 15555555 c: 3FFFFFFF d: 3FFFFFE0 e: 01FFFFFF Also are padding bits always the most significant bits or could they be the least significant bits? Thanks guys EDIT 12/19/2010 5PM EST: Christoph has answered my question. Thanks! I had also asked (above) whether padding bits are always the most significant bits. This is cited in the rationale for the C99 standard, and the answer is no. I am playing it safe and assuming the same for C89. Here is specifically what the C99 rationale says for §6.2.6.2 (Representation of Integer Types): Padding bits are user-accessible in an unsigned integer type. For example, suppose a machine uses a pair of 16-bit shorts (each with its own sign bit) to make up a 32-bit int and the sign bit of the lower short is ignored when used in this 32-bit int. Then, as a 32-bit signed int, there is a padding bit (in the middle of the 32 bits) that is ignored in determining the value of the 32-bit signed int. But, if this 32-bit item is treated as a 32-bit unsigned int, then that padding bit is visible to the user’s program. The C committee was told that there is a machine that works this way, and that is one reason that padding bits were added to C99. Footnotes 44 and 45 mention that parity bits might be padding bits. The committee does not know of any machines with user-accessible parity bits within an integer. Therefore, the committee is not aware of any machines that treat parity bits as padding bits. EDIT 12/28/2010 3PM EST: I found an interesting discussion on comp.lang.c from a few months ago. Bitwise Operator Effects on Padding Bits (VelocityReviews reader) Bitwise Operator Effects on Padding Bits (Google Groups alternate link) One point made by Dietmar which I found interesting: Let's note that padding bits are not necessary for the existence of trap representations; combinations of value bits which do not represent a value of the object type would also do.

Developer IT