- ECS - 21 Updates
- A fairly simple encryption algorithm... - 2 Updates
- "IT is urbanizing, McDonald's gets it, but Woonsocket doesn't (yet)" - 2 Updates
| David Brown <david.brown@hesbynett.no>: Aug 08 03:37PM +0200 On 08/08/18 15:12, Rick C. Hodgin wrote: > On Wednesday, August 8, 2018 at 5:28:43 AM UTC-4, David Brown wrote: >> [snip] > Use them in your systems then. They are not something I need in my systems. But I certainly would have no fear of them. I've used random identifications with far fewer entropy bits than UUIDs with no fear of collisions. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 08 06:44AM -0700 On Wednesday, August 8, 2018 at 9:37:25 AM UTC-4, David Brown wrote: > They are not something I need in my systems. But I certainly would have > no fear of them. I've used random identifications with far fewer > entropy bits than UUIDs with no fear of collisions. It is an inappropriate and even foolish design, in my opinion, when used for unique ids. Tick tock, David san. -- Rick C. Hodgin |
| boltar@cylonHQ.com: Aug 08 02:17PM On Wed, 08 Aug 2018 15:33:55 +0300 >manipulate objects. An object is a region of storage. [ Note: A function >is not an object. [...] An object has a storage duration. [...] An >object has a type. [...]" Thats an object in the low level sense, not in the OO sense. An object in the latter has to be instantiated from a class or cloned from a prototype. If basic types were objects then that would make C an object oriented language too which clearly it is not. |
| boltar@cylonHQ.com: Aug 08 02:19PM On Wed, 08 Aug 2018 13:50:40 +0200 >responsibility). >Changing MAC addresses in order to gain wrongful access to a service - >more free Wifi in this case - is dishonest. Given a lot of these chains advertised free wifi and it was only when you got there you found out about the time limit I'm not going to well up with guilt over it. Thankfully those days are past anyway. |
| David Brown <david.brown@hesbynett.no>: Aug 08 04:43PM +0200 On 08/08/18 15:44, Rick C. Hodgin wrote: >> entropy bits than UUIDs with no fear of collisions. > It is an inappropriate and even foolish design, in my opinion, when > used for unique ids. Tick tock, David san. Fortunately, your opinion is not relevant here. I've explained why worrying about random UUID collisions is not sensible. If you don't understand the maths involved, that's fine - trust someone who does. I /do/ understand the maths - as does Mr. Flibble (who is the one actually using them here). A great many other people use UUIDs for all sorts of purposes - either they understand the maths, or they are willing to trust those who do. As for "tick tock", perhaps you think it is only a matter of time before it is inevitable that there will be a UUID collision. Mathematically, that is of course nonsense. But it /is/ possible to give some numbers. If a new UUID is generated by some programmer every second, there will come a point where there is at least a 50% chance that it will collide with a previous random UUID. That time will be in about 86 billion years - about 6 times the age of the universe. Call me irresponsible, but I'd say that at that point, it would not be my problem any more. |
| David Brown <david.brown@hesbynett.no>: Aug 08 04:52PM +0200 > latter has to be instantiated from a class or cloned from a prototype. If basic > types were objects then that would make C an object oriented language too which > clearly it is not. Like it or not, the C standard defines "object" in a specific way - and C++ defines it in the same way. It is /not/ the same meaning as the term used in "object oriented language". In C++, "object" means what the standards say it means. (And for most purposes, the language does not make a distinction between objects that are simple, standard types like "int" and class instantiations.) |
| David Brown <david.brown@hesbynett.no>: Aug 08 12:41PM +0200 > that the cheapo chinese NIC manufacturer is playing ball and not just assigning > them randomly and secondly a lot of (most?) cards support the ability to change > the MAC address on the fly. In linux its trival using the ifconfig command. Did you bother reading my post? I wrote that /one/ way that UUIDs can be generated is using the MAC address as part of it - but that purely random UUIDs are more common. I also wrote that a disadvantage of MACs is that they are not as unique as theory would suggest, because some manufacturers cheat, take short-cuts, or simply get things wrong. > assumed it was a different machine. > ** A lot still do to pop up personalised greeting messages whenever you log > into their network from any of their hotels if you've logged in before. As I said, some people are dishonest, making MAC addresses less unique than in theory. |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 08 06:04PM +0300 >> object has a type. [...]" > Thats an object in the low level sense, not in the OO sense. An object in the > latter has to be instantiated from a class or cloned from a prototype. It was yourself who introduced the topic of objects in this thread: "I'm not even sure he understands the difference between a class and an object in C++". Note the qualification you used - "in C++". Had you said "in OOP" or something, then indeed int would not qualify. But in C++ int is an object, period. Also, look at the name of the newsgroup you are posting. At any time one is talking about an "object" without qualification in this group this means "C++ object". > If basic > types were objects then that would make C an object oriented language too which > clearly it is not. No, it would not. Besides, the whole C standard is built upon the notion of object, see 3.15/1 in the latest C standard draft (http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf): "object - region of data storage in the execution environment, the contents of which can represent value" The C standard is full of statements like: "An object declared as type signed char occupies the same amount of storage as a "plain" char object". |
| boltar@cylonHQ.com: Aug 08 03:13PM On Wed, 08 Aug 2018 16:52:08 +0200 >Like it or not, the C standard defines "object" in a specific way - and >C++ defines it in the same way. It is /not/ the same meaning as the >term used in "object oriented language". In C++, "object" means what Quite. So lets drop the pedantry shall we? |
| boltar@cylonHQ.com: Aug 08 03:21PM On Wed, 08 Aug 2018 18:04:08 +0300 >It was yourself who introduced the topic of objects in this thread: >"I'm not even sure he understands the difference between a class and an >object in C++". The meaning would be crystal clear to a native english speaker. Perhaps something got lost in translation for you. >No, it would not. Besides, the whole C standard is built upon the notion Yes it would be. You can't have it both ways, either object simply means an addressable non text area memory location defined by a name in the language or it means something instantiated from a class. If its the former then C is an OO language. Take your pick. >The C standard is full of statements like: >"An object declared as type signed char occupies the same amount of >storage as a "plain" char object". The english language is vague and words can have double meanings, it doesn't mean all meanings apply in all cases. I'd have thought that was obvious. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 08 08:34AM -0700 On Wednesday, August 8, 2018 at 10:43:19 AM UTC-4, David Brown wrote: > ...I've explained why > worrying about random UUID collisions is not sensible... It's a simple matter: collisions remain possible. It is an improper design given there are algorithms and protocols which can guarantee no collisions, even using far fewer bits, which give confidence that the possibility of failure at any time is not lurking over your head in uncertainty. To me it's a straight-forward train of thought to seek another solution. We'll never agree on this. I resign from the "discussion." I wish you well when you "place your bets." -- Rick C. Hodgin |
| Paavo Helde <myfirstname@osa.pri.ee>: Aug 08 06:38PM +0300 >> object in C++". > The meaning would be crystal clear to a native english speaker. Perhaps > something got lost in translation for you. You are not going to wiggle out of this, so better stop now. > addressable non text area memory location defined by a name in the language > or it means something instantiated from a class. If its the former then C is > an OO language. Take your pick. No, it's not. In the context of a standardized programming language which happens to define "object", object means exactly that and nothing else. >> storage as a "plain" char object". > The english language is vague and words can have double meanings, it doesn't > mean all meanings apply in all cases. I'd have thought that was obvious. That's why we have standards. That's why when you say "object in C++" this means "object in C++". |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 08 05:28PM +0100 > latter has to be instantiated from a class or cloned from a prototype. If basic > types were objects then that would make C an object oriented language too which > clearly it is not. This is not an OOP newsgroup it is a C++ newsgroup and C++ is a multi-paradigm programming language with object oriented features and NOT an object oriented programming language. An example of an object oriented programming language would be Java. Like it or not the default terms of reference which defines our *default* terminology for discussion used in this newsgroup is the C++ programming language as defined by the C++ ISO Standard which clearly states that in C++ an object isn't just an instance of a class. The fact that you were ignorant of this fact doesn't change anything including your fractal wrongness mainly because you are such an obtuse fucker who will not back down despite the evidence and admit his mistake. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 08 05:33PM +0100 > Given a lot of these chains advertised free wifi and it was only when you > got there you found out about the time limit I'm not going to well up with > guilt over it. Thankfully those days are past anyway. So you are just as egregious IRL as you are on the Internet. Thieving scum. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 08 05:45PM +0100 >>> the difference between a class and an object in C++. >> That's right mate I've been coding in C++ since 1993 and I don't know the > 1993? Really? You come across as someone who learnt it last week. So says you. > Well thats the way it seems. Also you don't seem to get the difference between > a compile time identifier such as namespaces and runtime identifiers such > as uuids and constantly conflate them. If you were intelligent enough to make the not too large mental leap you would have realized that I was wasn't conflating anything but that in my use the word "namespace" I was referring to namespaces in general and not a C++ namespace: in fact I believe I even mentioned XML namespaces in one of my replies. > Not in C++ it isn't. An object has a specific definition and an "int" is > not an object. Look it up. Perhaps you've spent too long with Smalltalk like > languages where all types are considered objects. See elsewhere in this thread for why you don't have a fucking clue what a C++ object is. >> Finger's crossed? Again educate yourself on the nature of UUIDs: chance of >> collision is very low. > But non zero unless you do it properly. See elsewhere in this thread for why this isn't an issue of any great importance. >> primary trigger for your fucktardery. > No, I saw some hard coded UUIDs in code you posted. I'm quite happy to repost > it for you if you've forgotten. "Hard coded" suggests I didn't automatically generate the UUID but that I just made it up; I didn't. >> Liar. > Believe what you like sonny. Using uuid's inappropriately is a dumb coders > idea of what smart coding is. Given the fractal wrongness on several issues that you have displayed in this thread I think it is safe to continue with the assumption that you are fucking clueless. >> identification for a class is. > Which given the nature of classes being fixed in number at compile time is > a trivial exercise. ECS component classes created independently by different people on different projects that use my ECS need to be unique with respect to each other to ensure any inter-operation wouldn't be an issue. In case you haven't noticed people share a lot more code today than they did even decade ago. >> serialized to a file/database/script. > Presumably by serialised you mean dumped into json or XML. You still don't > need a uuid for that. I need a UUID for my use-cases. > Thats because its not a uuid you mouth breathing muppet. Which part of the > word "encryption" didn't you understand? Its a diffie hellman key. The point > was to demonstrate that hex numbers are not easy to grok. And I repeat: hex numbers are the canonical way to represent UUIDs even in code. >> Someone else wrote my ECS? Amazing given that I haven't finished >> implementing it. > Ah, so its your abortion. No wonder you're so defensive. Correcting your vomit replies isn't being defensive it is just being helpful to other casual readers of this thread. Again I repeat: get a fucking clue you fucktarded cockwomble. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| David Brown <david.brown@hesbynett.no>: Aug 08 07:09PM +0200 >> C++ defines it in the same way. It is /not/ the same meaning as the >> term used in "object oriented language". In C++, "object" means what > Quite. So lets drop the pedantry shall we? As long as you are happy that in a C++ discussion on c.l.c++, "object" means what C++ says it means - and not what you apparently thought it meant. When you are in a Java newsgroup, or a Smalltalk newsgroup, you can use their terms - when you are in a C++ newsgroup, use C++ terms. It makes discussions /so/ much easier, and saves pointless arguments where one side is so clearly wrong. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 08 01:09PM -0700 On 8/7/2018 1:46 PM, Scott Lurndal wrote: >> MAC'ed. So the receivers can verify some sort of authenticity. > That's true of any traffic, hence the existence of TLS. There's nothing > special about a UUID vis-a-vis traffic security. Right. Rick now needs to worry about possible HMAC and/or MAC collisions. If he sends a UUID, and it meets the dreaded "something in the middle" that maliciously alters even a single bit, well... Not good. ;^) |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 08 04:34PM -0400 On 08/08/2018 04:09 PM, Chris M. Thomasson wrote: > Right. Rick now needs to worry about possible HMAC and/or MAC > collisions. If he sends a UUID, and it meets the dreaded "something in > the middle" that maliciously alters even a single bit, well... Not good. Separate issue, and one rooted in hardware and infrastructure that may be outside of my control. Very little you can do about that. You can only encrypt and work with your payload, not the delivery system. -- Rick C. Hodgin |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 08 02:05PM -0700 On 8/7/2018 5:21 PM, Rick C. Hodgin wrote: >> Not every program has access to nuclear launch codes. > Agreed. With the ECS in question, I mean seriously ... what's the > worst that could happen? :-) In the context of a game, what about cheating and forging UUID's? |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 08 02:15PM -0700 On 8/8/2018 2:05 PM, Chris M. Thomasson wrote: >> Agreed. With the ECS in question, I mean seriously ... what's the >> worst that could happen? :-) > In the context of a game, what about cheating and forging UUID's? You can try to double check UUID's with the "central" data farm, however, they still need to be HMAC or MAC'ed. It seems to want to boil down to the forging of UUID's and exploits in the hash used for the MAC's. Design your own crypto strong hash. I have some highly experimental algorithms based on fractals, still not sure about their strength. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 08 10:19PM +0100 On 08/08/2018 21:34, Rick C. Hodgin wrote: > Separate issue, and one rooted in hardware and infrastructure that may > be outside of my control. Very little you can do about that. You can > only encrypt and work with your payload, not the delivery system. And Satan invented fossils yes? /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 08 01:58PM -0700 When you get some time to spare, and are interested, read all: http://funwithfractals.atspace.cc/ct_cipher and try this C and Python code for starters: https://pastebin.com/raw/feUnA3kP (C) https://pastebin.com/raw/NAnsBJAZ (Python Test Vector) Now, notice in my crude little paper, it recommends using a TRNG! Well, this experimental test code uses the damn rand() function in C. It should be output from a TRNG. Anyway, here is the programs usage: Usage: __________________________ Usage: program in_file out_file mode_flag mode_flag -e is encrypt where the in_file gets encrypted as out_file mode_flag -d is decrypt where the in_file gets decrypted as out_file Example: program plaintext ciphertext -e program ciphertext plaintext_decrypt -d __________________________ Can you get it to work? Can you get the encrypt/decrypt cycle to work in C? Thanks. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 08 02:02PM -0700 On 8/8/2018 1:58 PM, Chris M. Thomasson wrote: > and try this C and Python code for starters: > https://pastebin.com/raw/feUnA3kP > (C) [...] > Can you get it to work? Can you get the encrypt/decrypt cycle to work in C? ARGH! I accidentally posted my C code to comp.lang.c++. Talk about encryption: Sorry. I am posting it again in comp.lang.c: https://groups.google.com/d/topic/comp.lang.c/a53VxN8cwkY/discussion |
| Lynn McGuire <lynnmcguire5@gmail.com>: Aug 08 02:59PM -0500 "IT is urbanizing, McDonald's gets it, but Woonsocket doesn't (yet)" https://www.cringely.com/2018/08/08/it-is-urbanizing-mcdonalds-gets-it-but-woonsocket-doesnt-yet/ "My favorite UK TV producer once had to sell his house in Wimbledon and move to an apartment in Central London just to get his two adult sons to finally leave home. Now something similar seems to be happening in American IT. Some people are calling it age discrimination. I'm not sure I'd go that far, but the strategy is clear: IT is urbanizing — moving to city centers where the labor force is perceived as being younger and more agile." I am not sure that I agree with the Cringe but he does make some sense. Getting us old programmers (I am 58 and building Windows apps in C++ and Fortran) to work on cloud apps is tough. Of course, we grew up in the cloud but we called it mainframes back then. Lynn |
| legalize+jeeves@mail.xmission.com (Richard): Aug 08 08:56PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >I am not sure that I agree with the Cringe but he does make some sense. >Getting us old programmers (I am 58 and building Windows apps in C++ and >Fortran) to work on cloud apps is tough. You should try it, it's fun. :-) I recommend playing with a CRUD app using Django or a big asynchronous I/O mashup using NodeJS. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment